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Avant-propos 



Lorsque, le 2 juin 1875, le Canadien Alexandre Graham Bell tente de transformer des 
ondes sonores en impulsions electromagnetiques, nul n' imagine que ce professeur de 
physiologie vocale, specialise dans l'enseignement du langage pour sourds et muets, 
allait inventer le telephone. 

Accompagne de son assistant Thomas Watson, Bell experimente le premier modele de 
telephone a distance limitee et a correspondance reduite : places dans deux pieces 
distinctes, les deux physiciens disposent entre eux un fll conducteur dont une extremite 
est munie d'une lamelle reliee a un electroaimant. L' experience consiste a ecarter cette 
lamelle de 1' electroaimant puis a la relacher. Le resultat est prodigieux : un son se 
propage sur le fll conducteur jusqu' a parvenir a 1' autre extremite du fll. II faudra moins 
d'un an au scientiflque Bell, tout juste age de 28 ans, pour perfectionner son prototype et 
rendre les transmissions d'un bout a l'autre d'un fll conducteur parfaitement intelligibles 
pour l'oreille humaine. 

Le 10 mars 1876, a Boston, Bell communique a distance avec son assistant en pronon- 
gant sa celebre phrase : « Monsieur Watson, veuillez venir dans mon bureau, je vous 
prie. » Quelques mois plus tard, le telephone entre dans sa phase de commercialisation. 
Des operatrices prennent en charge la demande de connexion et assurent la liaison entre 
les correspondants, et le succes est au rendez-vous. 

En 1964, en pleine guerre froide, le projet d'un reseau informatique totalement distribue 
et dedie aux communications militaires est refuse par les autorites a son initiateur, Paul 
Baran. Presque en parallele, les travaux du fran^ais Louis Pouzin, mettant au point le tout 
premier reseau a commutation de paquets, emule la communaute scientiflque. Au debut 
des annees 70, un reseau imagine par des laboratoires de recherche academiques voit le 
jour. Constitue de quatre ordinateurs repartis dans le monde, il est realise par l'ARPA 
(Advanced Research Projects Agency) et prend le nom d' ARPANET. Au meme moment, 
en France, le projet Cyclades relie plusieurs ordinateurs par une technologie de data- 
gramme. 

Ces prototypes demontrent la faisabilite du reseau mondial qui se developpera sous le 
nom d' Internet, et dont le protocole IP (Internet Protocol) est l'embleme. II faudra toute- 
fois attendre 1989 pour que Tim Berners-Lee invente le protocole HTTP et propose des 
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liens hypertextes avec le langage HTML pour que le grand public commence a se 
passionner pour le Word- Wide Web. 

Depuis lors, le reseau IP n'a cesse de croitre et d'obtenir les faveurs des acteurs des tele- 
communications. Avec les reseaux IP, la telephonie connait un nouvel elan. Elle se place 
a la jonction du monde des telecommunications et de celui des reseaux informatiques. 
Les professionnels ont rapidement compris l'interet d'une convergence vers un reseau 
entierement IP. De son cote, le grand public se passionne pour des programmes tels que 
Skype, qui allient simplicite et performance, a des tarifs ultra-competitifs. 

Plus qu'un nouveau support de 1' information, c'est un nouveau mode de communication 
qui est invente avec la telephonie sur IP. Les fonctionnalites etant accrues, une communi- 
cation ne se limite plus qu'a la parole telephonique, mais peut s'enrichir de multiples 
facettes, qui facilitent son usage, comme la video associee a la parole telephonique ou le 
service de presence des softphones, qui indique en temps reel la disponibilite de ses 
contacts. 

Cet enrichissement s'accompagne de performances souvent superieures a celles du tradi- 
tionnel reseau RTC. La qualite d'une communication de ToIP est parfois tellement bonne 
qu'il est impossible de discerner si un correspondant est proche ou a l'autre bout du 
monde. Peu a peu, les habitudes comportementales des consommateurs sont modifiees. 
A des couts tres raisonnables et avec une telle commodite d' utilisation, les distances sont 
abolies, l'interactivite est fidele, et les communications telephoniques deviennent tout a 
la fois plus longues, plus conviviales et plus productives. 

L' emergence de la ToIP se poursuit inexorablement depuis plusieurs annees. Que Ton 
soit un particulier ou un professionnel, elle s'impose parallelement sur differents axes. 
Pour un utilisateur equipe d'un ordinateur, les solutions de ToIP de type Skype sont 
nombreuses. Si l'usage d'un ordinateur rebute, les FAI proposent des solutions 
packagees dans leur offre Internet de base. Dans ce modele, la ToIP tend a se substi- 
tuer a la telephonie fixe standard. Mais elle va aussitot plus loin en introduisant 
progressivement sur le marche de la telephonie sans fil, avec les technologies IP sans 
fil adequates, comme Wi-Fi ou WiMax. Lorsque l'utilisateur n'a pas acces a un reseau 
IP, des terminaux hybrides lui permettent de basculer d'un reseau IP vers le reseau tele- 
phonique classique. En quelque sorte, la transition vers un reseau entierement IP se fait 
en douceur. 

Les contraintes de cette nouvelle technologie n'en sont pas moins nombreuses, de meme 
que les verrous a lever, en termes de disponibilite, de qualite de service, de securite et de 
mobilite. Ces contraintes sont a evaluer differemment selon le type de communication 
considere. Un service de telephonie ne peut s'accommoder d'une pietre qualite d'ecoute 
sous peine d'etre inutilise. II necessite des ressources optimales. Le controle et la 
maitrise des communications telephoniques sur IP sont done des enjeux colossaux pour 
favoriser l'essor de cette technologie. 
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Objectifs de I'ouvrage 

L'objectif de ce livre est de faire comprendre, par la theorie et par la pratique, pourquoi la 
telephonie sur IP peut etre consideree aujourd'hui comme mature et en quoi elle peut 
avantageusement remplacer la telephonie standard de type RTC. Cela n'implique pas que 
les services exploitant cette technologie soient toujours a la hauteur des attentes des utili- 
sateurs. Simplement, les protocoles dedies a la gestion des flux multimedias sont dispo- 
nibles et eprouves pour satisfaire toutes ces exigences. 

Toutes les conditions sont reunies pour valoriser ce potentiel et faire de la ToIP une techno- 
logie dominante, en phase avec les besoins de tout type. 

Cet ouvrage s'adresse a un large public, aux professionnels comme aux particuliers. 
II peut etre lu et compris par toutes les personnes qui desirent decouvrir ou approfondir 
les vastes possibilites qu'offre la ToIP. 

Certains chapitres visent davantage des debutants, d'autres des etudiants, d'autres encore 
des professionnels du domaine. De nombreux chapitres sont independants et peuvent etre 
lus de fa^on non lineaire, sans necessiter de connaissances prealables, tandis que d'autres 
requierent des bases plus techniques, que I'ouvrage apporte de fa^on progressive. 

Organisation de I'ouvrage 

Ce livre se compose de deux grandes parties et d'une conclusion. 

La premiere partie est dediee aux notions fondamentales de la ToIP. Elle expose ses 
fondements theoriques et couvre un vaste etat de l'art des normalisations adoptees pour 
le controle et la gestion du multimedia en general et de la voix sur IP en particulier. Elle 
detaille 1' ensemble des specificites des flux de telephonie sur IP et s'attarde sur les archi- 
tectures deployees ainsi que sur la maniere dont les communications sont etablies entre 
les interlocuteurs. 

Apres une presentation de la problematique et des contraintes de la ToIP (chapitres 1 et 
2), les trois principaux protocoles de signalisation, que sont H.323, SIP et MGCP, sont 
detailles (chapitres 3, 4 et 5). Nous evoquons ensuite la qualite de service (chapitre 6), 
1' architecture de securite (chapitre 7), autant de points cruciaux pour une application 
aussi sensible que la telephonie. 

La deuxieme partie rassemble plusieurs composants disparates qui constituent un reflet 
de ce que recouvre aujourd'hui la ToIP dans la pratique. Les logiciels de telephonie sur 
IP (ou softphones) en sont une composante importante, que nous presentons de maniere 
generale (chapitre 8), avant de mettre 1' accent sur les plus connus, tels que Skype (chapi- 
tre 9), WLM et Yahoo! Messenger (chapitre 10) puis Jabber et Google Talk (chapitre 1 1). 
Bien que certains d' entre eux n'ambitionnent pas directement de traiter de la telephonie, 
ils en sont les vecteurs, et nous verrons qu'ils ne respectent pas toujours les protocoles de 
la standardisation. 
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Asterisk constitue egalement une tendance marquee de ces dernieres annees. Ce logiciel 
impressionnant permet de realiser a moindre cout, dans un cadre industriel comme 
domestique, un commutateur telephonique, ou PBX, avec une gamme de services asso- 
cies, tels que la redirection d'appel, le repondeur telephonique ou la conference audio. 
II initie une petite revolution dans le monde des telecoms, en rempla^ant un modele opaque 
par un modele ouvert, ce qui permet une large democratisation des techniques mises en 
oeuvre. Toutefois, ses bases demeurent encore delicates a comprendre. C'est pourquoi 
nous consacrons un long developpement (chapitre 12) sur cette thematique afin de fournir 
au lecteur les elements cles du fonctionnement d' Asterisk. 

Nous detaillons ensuite les offres de ToIP des FAI (chapitre 13) et presentons les techni- 
ques utilisees pour traverser les pare-feu et les NAT (chapitre 14), un sujet important 
compte tenu du fait que le NAT reste tres employe, chez les particuliers comme chez les 
professionnels. 

La troisieme partie de l'ouvrage revient sur les cinq questions cles a se poser avant de 
passer a la telephonie sur IP et offre, en conclusion, une vision des futurs developpements 
attendus (chapitre 15). En particulier, et c'est la grande nouveaute de cette deuxieme 
edition, 1'IMS est longuement developpe en fin d'ouvrage (chapitre 16). 

Nous esperons que cette deuxieme edition, plus riche en contenu que la precedente et 
actualisee, reflete les principales problematiques, technologies et tendances, actuelles et a 
venir, de la telephonie sur IP, et permette de mieux comprendre les caracteristiques et les 
enjeux afin d'en etre, comme utilisateurs avertis ou fournisseurs de services, les acteurs 
de demain. 
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Theorie de laTolP 



L'objectif de cette partie est de presenter le socle theorique sur lequel repose la tele- 
phonie sur IP. 

Les deux premiers chapitres evoquent l'interet et les difficultes soulevees par la ToIR 

Le chapitre 1 introduit la problematique de ToIP, c'est-a-dire le transport de la parole 
dans le cadre de la telephonie, qui implique un processus temps reel. Nous expliquons 
quels sont les enjeux poses par la voix sur IP, ce a quoi elle peut se substituer et quels 
benefices il est possible d'en tirer. 

Le chapitre 2 detaille les contraintes imposees par la ToIP. Pour etre pleinement fonc- 
tionnel, un service de telephonie sur IP a des exigences fortes vis-a-vis des terminaux 
utilises comme du reseau exploite. Nous verrons comment caracteriser ces contraintes 
et comment les mesurer. 

Les trois chapitres suivants presentent les protocoles de signalisation standardises de 
la ToIP. 

Le chapitre 3 decrit le protocole H.323. Celui-ci a longtemps fait office de reference en 
matiere de protocole de signalisation pour le multimedia en general, et pour la telepho- 
nie sur IP en particulier. Porteur d'un fort heritage du monde des telecoms, il s'est 
impose sur le marche. Nous montrons sur quelle architecture il repose et comment 
s'effectuent les communications qu'il met en place. 

Le chapitre 4 decrit le protocole SIP, concurrent du protocole H.323 et disposant 
d'atouts remarquables qui favorisent son emergence. Nous montrons pourquoi ce 
protocole est en passe de detroner H.323, pourquoi il s'integre mieux dans un reseau 
IP, comment il simplifle les communications et comment on l'utilise. 

Le chapitre 5 decrit le protocole MGCP, un autre protocole de signalisation, qui est 
complementaire de H.323 et SIP. Par sa vision d'operateur et en offrant la faculte de 
concentrer 1' intelligence du reseau au sein d'entites specialisees, le protocole MGCP 
s'est impose, tant et si bien que ses evolutions peinent a justifler leur utilite. Nous 
montrons en quoi le protocole MGCP allie simplicite et puissance et de quelle maniere 
il fonctionne. 

Les deux derniers chapitres de cette partie s'interessent aux questions de qualite de 
service, d' architectures reseau et de securite. 



Le chapitre 6 expose les differents protocoles et technologies permettant de mettre en 
place une gestion de la qualite de service pour la telephonie sur IP. La qualite de service 
apportee aux flux de parole telephonique est primordiale. Nous detaillons les protocoles 
a mettre en ceuvre pour la maitriser dans un reseau. 

Le chapitre 7 fournit les principales caracteristiques des architectures reseau dediees a la 
ToIP et presente quelques notions importantes relatives a la securite de la telephonie sur 
IP. Les flux telephoniques pouvant emprunter un reseau partage par d'autres categories 
de donnees, nous indiquons, selon les types de reseaux, quelles sont les adaptations a 
considerer et comment faire pour proteger les flux de parole telephonique. 



1 



Problematiques de laTolP 



La telephonie est un des moyens de communication preferes des etres humains, et le 
nombre de terminaux telephoniques vendus dans le monde ne cesse d'augmenter. 

La figure 1.1 illustre le nombre de terminaux pouvant servir de terminal telephonique. 
On peut noter que le nombre des terminaux mobiles depasse largement celui des termi- 
naux fixes. On peut egalement noter que le nombre de terminaux fixes continue 
d'augmenter, quoique nettement moins que celui des mobiles. La figure indique en outre 
le nombre de terminaux, fixes ou mobiles, integrant des fonctions multimedias. Toutes 
ces courbes revelent la croissance globale de la telephonie. 
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Parte I 



La telephonie a ete une veritable poule aux oeufs d'or pour les operateurs, qui ont long- 
temps maintenu leurs tarifs a des niveaux assez eleves, alors meme que leurs infras- 
tructures etaient largement amorties. 

Aujourd'hui, la position de ces operateurs est rapidement menacee par l'arrivee massive 
de la telephonie sur IP, dont la tarification tend vers la gratuite. En France, fin 2006, la 
telephonie sur IP represente deja pres de 50 % du marche de la telephonie. Aux environs 
de 2009, on estime que pres de 100 % du transport de la parole s'effectuera par l'interme- 
diaire de paquets IP. 

Nous donnerons au cours des sections qui suivent quelques indications sur les problema- 
tiques techniques de la telephonie par paquets. Nous examinerons ensuite les premieres 
grandes caracteristiques de cette technologie et terminerons en presentant les differents 
environnements de la telephonie IP : grand public, operateurs et entreprises. 



La telephonie par circuit et par paquets 



Dans la communication a transfert de paquets, toutes les informations a transporter 
sont decoupees en paquets pour etre acheminees d'une extremite a une autre du reseau. 
Cette technique est illustree a la figure 1.2. 

L'equipement terminal A souhaite envoy er un message a B. Le message est decoupe en 
trois paquets, qui sont emis de l'equipement terminal vers le premier noeud du reseau, 
lequel les envoie a un deuxieme noeud, et ainsi de suite, jusqu'a ce qu'ils arrivent a l'equi- 
pement terminal B. Dans l'equipement terminal les paquets rassembles reconstituent le 
message de depart. 



Figure 1.2 

La technique de 
transfert de paquets 



Equipement terminal A 



Equipement terminal B 



Message 



Message 



>aquet| ] | 1 | fl 




Le paquet peut en fait provenir de differents medias. Sur la figure 1.2, nous supposons 
que la source est un message compose de donnees, comme une page de texte preparee au 



Problematiques de la TolP 



Chapitre 1 | 

moyen d'un traitement de texte. Le terme message est cependant beaucoup plus vaste et 
recoupe toutes les formes sous lesquelles de 1' information peut se presenter. Cela va 
d'une page Web a un flot de parole telephonique representant une conversation. 

Dans la parole telephonique, 1'information est regroupee pour etre placee dans un paquet, 
comme illustre a la figure 1.3. Le combine telephonique produit des octets, provenant de 
la numerisation de la parole, c'est-a-dire le passage d'un signal analogique a un signal 
sous forme de et de 1, qui remplissent petit a petit le paquet. Des que celui-ci est plein, 
il est emis vers le destinataire. Une fois le paquet arrive a la station terminale, le proces- 
sus inverse s'effectue, restituant les elements binaires regulierement a partir du paquet 
pour reconstituer la parole telephonique. 

Equipement terminal A Equipement terminal B 

q t t Remplissage d'un paquet 




Figure 1.3 

Unflot depaquets telephoniques 

Le reseau de transfert est lui-meme compose de noeuds, appeles noeuds de transfert, relies 
entre eux par des lignes de communication, sur lesquelles sont emis les elements binaires 
constituant les paquets. Le travail d'un nceud de transfert consiste a recevoir des paquets 
et a determiner vers quel noeud suivant ces derniers doivent etre achemines. 

Le paquet forme done l'entite de base, transferee de noeud en noeud jusqu'a atteindre le 
recepteur. Ce paquet est regroupe avec d'autres paquets pour reconstituer 1'information 
transmise. L' action consistant a remplir un paquet avec des elements binaires en general 
regroupes par octet s'appelle la mise en paquet, ou encore la paquetisation, et Taction 
inverse, consistant a retrouver un flot d' octets a partir d'un paquet, la depaquetisation. 

L' architecture d'un reseau est deflnie principalement par la fa^on dont les paquets sont 
transmis d'une extremite du reseau a une autre. De nombreuses variantes existent pour 
cela, comme celle consistant a faire passer les paquets toujours par la meme route ou, au 
contraire, a les faire transiter par des routes distinctes de fa^on a minimiser les delais de 
traversee. 
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Pour identifier correctement toutes les composantes necessaires a la bonne marche d'un 
reseau a transfert de paquets, un modele de reference a ete mis au point. Ce modele defi- 
nit une partition de 1' architecture en sept niveaux, prenant en charge 1' ensemble des fonc- 
tions necessaires au transport et a la gestion des paquets. Ces sept couches de protocoles 
ne sont pas toutes indispensables, notamment aux reseaux sans visee generaliste. Chaque 
niveau, ou couche, offre un service au niveau superieur et utilise les services du niveau 
inferieur. 

Pour offrir ces services, les couches disposent de protocoles qui appliquent les algorithmes 
necessaires a la bonne marche des operations, comme l'illustre la figure 1.4. 



Figure 1.4 

Architecture proto- 
colaire d'un reseau 
a sept niveaux 



Equipement emetteur 



Entite de niveau 7 



Entite de niveau 6 



Entite de niveau 5 



Entite de niveau 4 



Entite de niveau 3 



Entite de niveau 2 



Entite de niveau 1 



Protocole de niveau 7 



Protocole de niveau 6 



Protocole de niveau 5 



Protocole de niveau 4 



Protocole de niveau 3 



Protocole de niveau 2 



Protocole de niveau 1 



Equipement recepteur 



Support physique 



Nous supposons ici que 1' architecture protocolaire est decoupee en sept niveaux, ce qui 
est le cas du modele de reference. Nous ne decrirons que succinctement les couches 
basses qui nous interessent. 

Le niveau 3 represente le niveau paquet : il definit les algorithmes necessaires pour que 
les entites de niveau 3, les paquets, soient acheminees correctement de l'emetteur au 
recepteur. Le niveau 7 correspond au niveau application. Le role du protocole de niveau 7 
est de transporter correctement l'entite de niveau 7, le message utilisateur, de l'equipement 
emetteur a l'equipement recepteur. 

Le niveau 2, ou niveau trame, permet de transferer le paquet sur une ligne physique. En 
effet, un paquet ne contenant pas de delimiteur, le recepteur ne peut en determiner la fin 
ni identifier le commencement du paquet suivant. Pour transporter un paquet, il faut done 
le mettre dans une trame, qui, elle, comporte des delimiteurs. On peut aussi encapsuler 
un paquet dans un autre paquet, lui-meme encapsule dans une trame. 

II est important de distinguer les mots paquet et trame de fa^on a bien differencier les 
entites qui ne sont pas transportables directement, comme le paquet IP, et les entites 
transportables directement par la couche physique, comme les trames Ethernet ou 
ATM. 

Dans la telephonie sur IP, une suite d' octets de telephonie est encapsulee dans un paquet 
IP de niveau 3, lui-meme encapsule dans une trame vehiculee sur le support physique. 
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Cependant, comme la telephonie est une application temps reel, les paquets ne peuvent 
attendre trop longtemps dans le reseau. II faut done introduire des controles afln de 
permettre une traversee rapide du reseau. Nous detaillons ces controles au chapitre 6. 

La problematique de base de la telephonie 

La voix sur IP adresse deux types d' applications : celles qui, comme la telephonie, 
mettent en jeu une interaction humaine, laquelle implique un temps de transit tres 
court, et celles qui transportent des paroles unidirectionnelles, qui n' exigent pas de 
temps reel. Cette derniere categorie rassemble essentiellement des transferts de fichiers 
contenant de la parole. Dans ce livre, nous nous interessons uniquement a la parole 
telephonique. 

La telephonie transportee par paquets, et plus particulierement par paquet IP, permet 
d'integrer dans un meme reseau les services de donnees et la telephonie. Les entreprises 
sont de plus en plus nombreuses a integrer leur environnement telephonique dans leur 
reseau a transfert de paquets. Les avantages de cette integration sont, bien sur, la baisse 
des frais de communication, mais aussi la simplification de la maintenance de leurs 
reseaux, qui passent de deux (telephonie et donnees) a un seul (donnees). 

La difficulte de la telephonie par paquets reside dans la tres forte contrainte temporelle 
due a l'interaction entre individus. Le temps de latence doit etre inferieur a 300 ms si Ton 
veut garder une interaction humaine acceptable. Si Ton souhaite une bonne qualite de la 
conversation, la latence ne doit pas depasser 150 ms. 

Un cas encore plus complexe se produit lorsqu'il y a un echo, e'est-a-dire un signal qui 
revient dans l'oreille de l'emetteur. L'echo se produit lorsque le signal rencontre un 
obstacle, comme l'arrivee sur le combine telephonique. L'echo qui repart en sens inverse 
est numerise par un codec (codeur-decodeur) et traverse sans probleme un reseau nume- 
rique. La valeur normalisee de la latence de l'echo etant de 56 ms, pour que l'echo ne soit 
pas genant a l'oreille, il faut que le temps aller ne depasse pas 28 ms, en supposant un 
reseau symetrique prenant le meme temps de transit a Taller qu'au retour. II faut done 
que, dans les equipements terminaux, les logiciels extremite soient capables de gerer les 
retards et de resynchroniser les octets qui arrivent. Les equipements modernes, comme 
les terminaux GSM, possedent des suppresseurs d'echo evitant cette contrainte tempo- 
relle forte. 

Une autre caracteristique essentielle de la telephonie provient du besoin d'avertir par une 
sonnerie la personne qui est appelee. La communication telephonique est pour cela decom- 
posee en deux phases : une premiere permettant d'avertir le destinataire, et une seconde 
correspondant au transport de la parole proprement dite. II existe en realite une troisieme 
phase, qui consiste en la finalisation de la communication lorsqu'un des deux terminaux 
raccroche. Cette phase utilise le meme type de protocole que la premiere : un protocole 
de signalisation. 
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Comparaison avec la telephonie classique 

La telephonie classique, dite par circuit, presente les memes contraintes temporelles que 
la telephonie par paquet. Le temps de transit doit etre limite pour satisfaire le besoin 
d'interactivite entre individus. 

La limitation du temps de transit entre l'emetteur et le recepteur est relativement simple 
a realiser dans une technologie circuit. Les ressources etant reservees, la voie est toujours 
degagee sur le circuit, et les ressources appartiennent uniquement aux signaux qui transi- 
ted entre l'emetteur et le recepteur. En revanche, dans un transfert de paquets, aucune 
ressource n'est reservee, et il est impossible de savoir quel sera le temps d'attente des 
paquets dans les nceuds de transfert. 

Dans la premiere generation de telephonie, les signaux etaient analogiques. lis parcou- 
raient le circuit sous la meme forme que le son sortant de la bouche et n'utilisaient que 
3 200 Hz de bande passante. lis sont ensuite devenus numeriques. 

Dans la telephonie traditionnelle numerique, le signal analogique est numerise grace a un 
codeur-decodeur, appele codec. Le codec transforme le signal analogique en une suite de 
et de 1. Le temps de transit est du meme ordre de grandeur que le transfert du signal 
analogique, car le signal ne s'arrete nulle part. La seule perte de temps pourrait provenir 
du codec, mais ces equipements tres rapides ne modifient pas fondamentalement le temps 
de transit. En revanche, dans un reseau a transfert de paquets, de nombreux obstacles se 
dressent tout au long du cheminement des informations binaires. 

L' element le plus contraignant de 1' application de telephonie par paquet reste le delai 
pour aller d'une extremite a 1' autre, puisqu'il faut traverser les deux terminaux, emetteur 
et recepteur, de type PC par exemple, ainsi que les modems, les reseaux d'acces, les 
passerelles, les routeurs, etc. 

On peut considerer que le temps de traversee d'un PC et de son codec demande quelques 
millisecondes, la paquetisation de 5 a 16 millisecondes, la traversee d'un modem quel- 
ques millisecondes egalement, celui d'un routeur ou d'une passerelle de l'ordre de la millise- 
conde (s'il n'y a aucun paquet en attente) et celui d'un reseau IP quelques dizaines de 
millisecondes. 

L' addition de ces temps montre que la limite maximale de 300 ms permettant l'interacti- 
vite est rapidement atteinte. La figure 1.5 illustre ce processus. 

Le deroulement d'une communication telephonique sur IP parcourt les cinq grandes etapes 
suivantes : 

1. Mise en place la communication. Une signalisation demarre la session. Le premier 
element a considerer est la localisation du recepteur ( User Location). Elle s'effectue 
par une conversion de l'adresse du destinataire (adresse IP ou adresse telephonique 
classique) en une adresse IP d'une machine qui puisse joindre le destinataire (qui 
peut etre le destinataire lui-meme). Le recepteur peut etre un combine telephonique 
classique sur un reseau d'operateur telecoms ou une station de travail (lorsque la 
communication s'effectue d'un combine telephonique vers un PC). Le protocole 
DHCP (Dynamic Host Configuration Protocol) et les passerelles specialisees (gate- 
keeper) sont employes a cette fin. 
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Figure 1.5 

Equipements a traverser par une communication telephonique sur IP 



2. Etablissement de la communication. Cela passe par une acceptation du terminal 
destinataire, que ce dernier soit un telephone, une boite vocale ou un serveur Web. 
Plusieurs protocoles de signalisation sont utilises pour cela, en particulier le proto- 
cole SIP (Session Initiation Protocol) de 1'IETF. Comme son nom l'indique, SIP est 
utilise pour initialiser la session. Une requete SIP contient un ensemble d'en-tetes, 
qui decrivent l'appel, suivis du corps du message, qui contient la description de la 
demande de session. SIP est un protocole client-serveur, qui utilise la syntaxe et 
la semantique de HTTP. Le serveur gere la demande et fournit une reponse au client. 

Trois types de serveurs gerent differents elements : un serveur d'enregistrement 
(Registration Server), un serveur relais (Proxy Server) et un serveur de redirection 
(Redirect Server). Ces serveurs travaillent a trouver la route : le serveur proxy deter- 
mine le prochain serveur (Next-Hop Server), qui, a son tour, trouve le suivant, et ainsi 
de suite. Des champs supplementaires de l'en-tete gerent des options, comme le 
transfert d'appel ou la gestion des conferences telephoniques. 

3. Transport de Pinformation telephonique. Le protocole RTP (Real-time Transport 
Protocol) prend le relais pour transporter 1' information telephonique proprement 
dite. Son role est d' organiser les paquets a 1' entree du reseau et de les controler a la 
sortie de fa^on a reformer le flot avec ses caracteristiques de depart (verification du 
synchronisme, des pertes, etc.). C'est un protocole de niveau transport, qui essaye de 
corriger les defauts apportes par le reseau. 

4. Changement de reseau. Un autre lieu de transit important de la TolP est constitue 
par les passerelles, qui permettent de passer d'un reseau a transfert de paquets a un 
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reseau a commutation de circuits, en prenant en charge les problemes d'adressage, de 
signalisation et de transcodage que cela pose. Ces passerelles ne cessent de se multiplier 
entre FAI et operateurs telecoms. 

5. Arrivee au destinataire. De nouveau, le protocole SIP envoie une requete a la pas- 
serelle pour determiner si elle est capable de realiser la liaison circuit de fa^on a 
atteindre le destinataire. En theorie, chaque passerelle peut appeler n'importe quel 
numero de telephone. Cependant, pour reduire les couts, mieux vaut choisir une pas- 
serelle locale, qui garantit que la partie du transport sur le reseau telephonique classique 
est le moins cher possible. 

Cet exemple classique illustre la relative complexity de la telephonie sur IP. De nombreu- 
ses variantes existent, mais elles ne different que par les protocoles utilises. A cette 
complexity s'ajoutent les problemes lies a la traversee du reseau, qui doit garantir des 
temps de transit acceptables pour que 1' application telephonique puisse se derouler dans 
de bonnes conditions. 



Avantages de la TolP 

La telephonie n'a jamais ete une application simple. Les contraintes temps reel et de 
synchronisation pesent lourdement sur sa mise en ceuvre, et la telephonie par paquet ne 
fait que compliquer le transport. 

Cependant, plusieurs raisons expliquent le succes de la telephonie par paquet, et plus 
specifiquement de la telephonie sur IP : 

• Convergence. Quel que soit le type de donnees vehiculees, le reseau est unique : 
les flux de voix, de video, de textes et d'applicatifs transitent sur le meme reseau. 
Les communications deviennent plus riches, et sans avoir besoin de multiplier les 
canaux de transport. Les utilisateurs peuvent, par exemple, envoyer un compte 
rendu d'activite en meme temps qu'ils telephonent a leur correspondant. Pour les 
utilisateurs, la convivialite est accrue. En entreprise, la productivity est amelioree. 
Pour les administrateurs, un seul reseau est a administrer, ce qui simplifie grandement la 
gestion. 

• Optimisation des ressources. Le reseau IP utilisant un transfert de paquets, l'utilisa- 
tion des ressources est optimisee en comparaison des solutions de type commutation 
de circuits. Dans le reseau RTC, qui est a commutation de circuits, des ressources sont 
dediees pour toute la duree de la communication, qu' elles soient utilisees ou non. Or 
les tres nombreux silences d'une conversation telephonique rendent le dimensionne- 
ment du canal reserve systematiquement trop grand. Pour que la voix supporte simul- 
tanement la superposition des deux paroles correspondant aux deux intervenants d'une 
communication telephonique (full-duplex), les reseaux RTC doivent allouer pour 
chaque intervenant des canaux differents, Tun en emission, l'autre en reception. Dans 
la pratique, lors d'une conversation telephonique, une seule personne parle en meme 
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temps. Les ressources sont done globalement gaspillees. C'est pourquoi la reservation 
effectuee dans les reseaux RTC represente un cout nettement superieur a celui des 
reseaux IP. 

• Cout de transport quasiment nul. Grace a 1' integration de la telephonie parmi de 
nombreuses autres applications, le cout du transport devient pratiquement nul. Le 
reseau permettant d'effectuer le transport est le reseau coeur des operateurs, celui qui 
effectue tous les transports de donnees. Ces operateurs, qui etaient auparavant 
obliges de maintenir au moins deux reseaux, celui de telephonie et celui de donnees, 
n'en ont plus qu'un seul a maintenir. L'integration supplementaire de la television 
dans le reseau de donnees fait egalement chuter les couts de transport de cette appli- 
cation. 

• Services exclusifs. Certains services sont propres aux reseaux IP. Par exemple, le 
service de presence, consistant a detecter si un utilisateur est connecte au reseau ou 
non, ne necessite aucune reservation de ressources dans un reseau IP, a la diffe- 
rence du reseau RTC. De fa^on analogue, pour le nomadisme des utilisateurs, il est 
plus simple de passer, partout dans le monde, par le reseau IP plutot que par le reseau 
RTC. 

• Disparition des commutateurs locaux. Liee a la precedente, cette nouvelle donne 
resulte de la possibilite de gerer les telephones depuis le reseau de l'operateur (systeme 
Centrex). Des solutions intermediaries, comme les PBX-IP, permettent de passer petit 
a petit des circuits numeriques aux liaisons paquet IP. 

La telephonie devient ainsi une application du reseau IP comme une autre, si ce n'est 
qu'elle necessite une qualite de service particuliere. De ce fait, les modems ADSL qui 
amenent chez 1' utilisateur la connectivity IP constituent la porte d' entree de la telephonie 
IP. Le modem l'integre avec les applications de donnees (messagerie, transfert de 
fichiers, P2P), la television, la visiophonie, etc. 

Debut 2007, cette integration n'etait pas encore finalisee puisque la plupart des postes 
telephoniques ne sont pas encore des postes IP capables d'emettre directement des 
paquets IP. II faut un point de connexion specifique sur le modem pour indiquer que le 
flux est une parole telephonique. 

De meme, le flux de television se distingue des autres applications par un acces specifi- 
que sur le modem. Cependant, des que les telephones et les televisions seront IP, le 
reseau domestique ne distinguera plus ces applications particulieres, et ce sera le modem 
qui, en filtrant les flux, decouvrira les paquets de telephonie et les paquets de television 
pour les traiter en consequence. 

Cette differentiation est illustree aux figures 1.6 et 1.7. La premiere presente l'etat actuel, 
ou les flux de donnees, de video et de telephonie sont differencies par la prise par 
laquelle ils transitent, et la seconde celui de demain, ou tous les flux sont integres sur 
le reseau domestique et sont differencies par le biais d'un filtre applicatif dans le modem 
ADSL. 
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Figure 1.6 

Differentiation de trafic 
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Figure 1.7 

Differentiation de trafic par un modem ADSL de nouvelle generation 



Cette meme evolution vaut pour les petites et moyennes entreprises, pour lesquelles le 
PBX-IP deviendra une sorte de gros modem ADSL, de nombreuses fonctionnalites etant 
exportees vers le reseau de l'operateur ou des fournisseurs de services particuliers. 
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Les solutions deTolP 

Le developpement de la TolP a vu se succeder sur plusieurs annees differentes generations 
de services et de configurations. 

La premiere generation de telephonie IP grand public a ete proposee par des operateurs 
alternatifs afln d'offrir des communications internationales a tarif local. Ce service 
consiste a rassembler un grand nombre de voies telephoniques classiques sur le commu- 
tateur local et a les encapsuler dans un meme paquet IP. Ce paquet IP peut devenir assez 
important suivant le nombre de voix multiplexees et le nombre d' octets de chaque voix. 

L'utilisateur se connecte en local sur le commutateur de l'operateur historique. L'opera- 
teur alternatif recupere les differentes voix et les multiplexe sur Internet ou sur une meme 
liaison IP, trans atlantique par exemple. A la sortie du reseau IP, les voies de parole 
retrouvent leur composition normale sur le commutateur local et sont envoyees de 
fa^on classique aux destinataires au travers de la boucle locale de l'operateur de tele- 
communications . 

Si la telephonie locale est gratuite, comme aux Etats-Unis, le cout total est approximati- 
vement egal a la tariflcation locale de depart. Les operateurs de telephonie classique 
suivent plus ou moins les memes principes, tout en tentant de preserver une marge bene- 
flciaire importante. D'ou une chute des prix beaucoup plus lente. 

Cette solution est illustree a la figure 1.8. 
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Figure 1.8 

La premiere generation de telephonie sur IP 

La deuxieme generation a vu les operateurs de telecommunications offrir des acces Internet 
au travers de la boucle locale via des modems standards permettant des debits de l'ordre 
de 50 Kbit/s. 

Sur cet acces Internet peuvent etre raccordes des ordinateurs personnels. Si l'ordinateur 
est equipe d'un micro et d'un haut-parleur, il est possible d'utiliser l'ordinateur personnel 
comme telephone et de faire transiter les paquets de telephonie sur Internet apres les 
avoir achemines sur la boucle locale de l'operateur. 



Theorie de la TolP 



Parte I 



Cette amelioration est illustree a la figure 1.9. 
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Figure 1.9 

La telephonie au travers de V ordinateur personnel 

Dans la troisieme generation, au lieu d'utiliser 1' ordinateur comme telephone, un combine 
analogique est connecte au PC, equipe d'une carte d' acquisition de la parole telephonique. 

L' ordinateur personnel joue ici le role d'une passerelle, transformant le signal analogique 
du combine en un flux d' octets de telephonie numerises par un codec integre a 1' ordina- 
teur. Les octets sont envoyes par un modem vers le routeur de l'operateur, auquel revient 
la charge de la paquetisation et de 1' envoi des paquets IP. 

Cette etape est illustree a la figure 1.10. 
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Figure 1.10 

Telephonie IP utilisant V ordinateur personnel comme intermediate 

La quatrieme generation est caracterisee par l'arrivee de modems ADSL munis de 
plusieurs prises, chacune prenant en charge un media particulier et un protocole associe. 

Le modem ADSL permet de connecter des telephones standards. Les conversions 
necessaires sont effectuees dans le modem, qui devient de ce fait une veritable Internet 
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Box, le travail specifique de la partie modem devenant mineur par rapport a 1' ensemble 
des fonctionnalites reseau realisees. 

La boucle locale de l'operateur transporte les paquets IP. Pour sa part, le telephone 
demeure analogique. 

Cette solution est illustree a la figure 1.11. 
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Figure 1.11 

Apparition du modem ADSL dans la chaine de transmission de la telephonie 

La cinquieme generation du processus aboutit a de la telephonie IP de bout en bout. La 
paquetisation est repoussee dans l'equipement terminal de l'utilisateur. Le telephone 
devient un telephone IP. 

La figure 1.12 illustre cette solution. Le telephone IP n'est pas connecte directement sur 
la boucle locale de l'operateur mais sur le reseau d'entreprise, lui-meme connecte a 
l'operateur. Le telephone IP fait en realite office de routeur. II integre en outre un codec 
et assure la paquetisation IP et 1' encapsulation des paquets IP dans une trame Ethernet. 
La trame Ethernet est ensuite transmise sur le reseau d'entreprise. 
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Figure 1.12 

La telephonie IP de bout en bout 
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Avec l'arrivee massive d'ordinateurs personnels sufflsamment puissants pour emuler un tele- 
phone IP, la TolP est devenue une telephonie de bout en bout gratuite, puisque la telephonie 
devient une application comme une autre transitant par 1' intermediate du modem ADSL. 

Du fait de cette configuration, de nouvelles applications ont fait leur apparition pour 
proposer des services grand public. Parmi celles-ci, Skype ou MSN (Microsoft Network) 
proposent de la telephonie sur IP de bout en bout. 

II faut dans les deux cas disposer d'un modem ADSL aux deux extremites de la communica- 
tion arm que le debit soit acceptable sur la boucle locale. Skype fait appel a une technique 
P2P (peer-to-peer) a des fins de simplicite et pour ne pas avoir a implementer un controle 
centralise. La signalisation de MSN est geree par une base de donnees centralisee mais 
qui peut etre distribute sur plusieurs sites. 

Nous examinons en detail dans la suite de l'ouvrage ces solutions de TolP, qu'elles 
proviennent des operateurs ou d' applications uniquement terminales. Le modem ADSL 
joue le role de codec et de paquetiseur. Le telephone est branche sur une prise specifique 
reliee au codec. La television et les donnees ont leur propre prise specifique. 

En cas d' utilisation d'un logiciel de telephonie sur l'ordinateur portable, le flux de tele- 
phonie est multiplexe avec 1' ensemble des donnees et n'est pas traite de fa^on specifique. 
On appelle cette solution, le Double-Play lorsqu'il y a un canal de donnees et un canal 
telephonique et Triple-Play lorsqu'un canal de television est ajoute (voir figure 1.13). 



Figure 1.13 
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Si Ton ajoute un canal supplemental, comme le canal de mobilite provenant d'un 
terminal mobile de type GSM/Wi-Fi, on parle de Quadruple-Play. Lorsque ce telephone 
est situe pres d'un modem incorporant un reseau Wi-Fi, le mobile se connecte en Wi-Fi. 
S'il n'est pas situe dans une zone Wi-Fi, le telephone utilise le mode GSM. II est possible 
de commencer a telephoner en Wi-Fi et de continuer en GSM lorsqu'on sort de la zone 
Wi-Fi. En sens inverse, le telephone peut eventuellement repasser en Wi-Fi. 

Cette solution est illustree a la figure 1.14. 



Figure 1.14 
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La figure 1.15 illustre la generation suivante, dite Penta-Play, dediee a la video mobile. 
Sur un mobile a ecran video, un utilisateur peut se connecter sur un reseau Wi-Fi et regar- 
der la television. La connexion avec le modem ADSL s'effectue en mode hertzien de 
type Wi-Fi. 

Dans cette solution comme dans la precedente, le telephone GSM/Wi-Fi peut se connecter a 
tous les modems de l'operateur Internet auquel 1' utilisateur a souscrit. 

La telephonie sur IP est encore peu presente dans le monde de la communication mobile, 
mais elle devrait se generaliser des que les acces Internet lui seront ouverts, ce que les 
operateurs interdisent aujourd'hui. Ce deploiement s'effectuera par 1' intermediate de 
1' Internet hertzien, mais prendra son essor veritable avec 1'arrivee des produits WiMax. 
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Figure 1.15 
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Pour le moment, les reseaux de mobiles peuvent transporter des paquets IP, qui ne 
sont jamais qu'un ensemble d'elements binaires au meme titre que toutes autres 
suites d'elements binaires. II est done possible de mettre en place des applications de 
telephonie sur un terminal mobile assez puissant. Le cout de la communication etant 
celui du transport des donnees, la telephonie n'est plus qu'une application parmi les 
autres. 



Questions posees par la mise en place de la TolP en entreprise 

Nous examinons dans cette section les questions a se poser lors de la mise en place d'un 
environnement de TolP en entreprise. Le cas des particuliers est different puisque e'est a 
l'operateur de resoudre les problemes lies a ces questions. 

Cinq questions principales se posent : 

• Securite. Autrefois, les reseaux etaient fortement securises grace a la notion de circuit. 
En entrant dans le monde IP, la telephonie rencontre un monde encore mal securise, 
qui connait des problemes d'authentification, de confidentialite et d'integrite. 

• Disponibilite. Autrefois, les reseaux avaient une disponibilite dite a cinq « neuf », 
signifiant qu'ils fonctionnaient 99,999 % du temps. Les meilleurs reseaux des operateurs 
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IP n'ont generalement qu'une disponibilite a trois « neuf » (99,9 % du temps). De 
nombreux autres reseaux IP ne sont disponibles qu'a 99 % du temps. 

• Gestion. Les trois reseaux de la generation precedente (donnees, parole, video) posse- 
daient trois systemes de gestion relativement simples. Avec l'integration, il n'y a plus 
qu'un seul systeme de gestion, de ce fait assez complexe. 

• Controle. Autrefois les reseaux etaient controles par des algorithmes assez simples. 
L'integration des differents flux dans le meme reseau complexifie enormement le 
controle de 1' ensemble. 

• Qualite de service. La qualite de service etant liee a 1' infrastructure, la nouvelle gene- 
ration de reseaux doit etre capable de prendre en charge les qualites de service de 
chaque application transitant sur le meme reseau, ce qui n'est pas facile. 

Dans la suite de l'ouvrage, nous nous penchons en detail sur les reponses techniques 
apportees a ces questions. Nous y reviendrons egalement en toute fin d'ouvrage pour 
synthetiser les elements de reponses qui auront ete apportes tout au long de ce livre. 

Revenons quelques instants sur la securite, qui passe par la mise en place de pare-feu, 
permettant dans la mesure du possible d'arreter les voies de parole interdites. Comme 
nous le verrons, ces solutions sont complexes et peu utilisees. Les pare-feu traditionnels 
filtrant les trafics a partir des numeros de port sont generalement incapables de stopper 
les flux de telephonic II est done necessaire de recourir a des pare-feu applicatifs, capables 
d' identifier les applications de niveau 7 (applicatif). 

Pour l'authentification et l'autorisation de l'emetteur, le chiffrement et la signature elec- 
tronique sont necessaires. II faut en outre verifier que la parole n'a pas ete deformee, 
voire remplacee par une autre. 

Le tableau 1.1 donne les idees de grandeur des durees et des couts engendres par l'indis- 
ponibilite du reseau. 





Tableau 1.1 -Taux de disponibilite et couts de I 


I'indisponibilite 




Nombre de « 


neuf » 


Disponibilite 


Duree d'indisponibilite 


Type de reseau 


Cout 


1 




90% 


36,5 j/an 




C 


2 




99% 


3,65 j/an 




2C 


3 




99,9 % 


8,8 h/an 


Bon reseau IP 


4C 


4 




99,99 % 


53 m in/an 




8C 


5 




99,999 % 


5 min/an 


Telephone classique 


16C 


6 




99,9999 % 


32 s/an 




32 C 



La duree d'indisponibilite passe de cinq minutes par an dans le cas d'un reseau tele- 
phonique classique a presque neuf heures de pannes dans un tres bon reseau IP. II est 
toujours possible d'augmenter la disponibilite par duplication des lignes ou des chemins. 
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Pour passer d'une disponibilite de trois « neuf » a une disponibilite de cinq « neuf », il 
faut cependant multiplier les couts par quatre. La derniere colonne du tableau montre que 
si le cout est de C pour un reseau de disponibilite 90 %, il est de 2 C pour gagner un 
« neuf », et il faut encore multiplier par 2 pour gagner un autre « neuf », etc. 

La gestion devient egalement de plus en plus complexe. De nombreux groupes de travail 
se sont formes depuis plusieurs annees pour promouvoir telle ou telle solution. 
Aujourd'hui, presque tout reste a faire du fait du passage de la gestion a des technologies 
IP. 

Le controle est dans une situation similaire. II est aujourd'hui quasiment impossible de 
controler efficacement un tres grand reseau d'operateur Internet. De nouvelles techniques 
sont en train d'emerger, comme les controles dits « autonomic » (parfois traduits en fran- 
£ais par « auto-organisants »), qui permettent d'automatiser la commande de la plupart 
des algorithmes de controle. Le terme « autonomic » indique un processus autonome et 
spontane. 

La qualite de service est un probleme primordial. A ce titre, elle est abondamment 
couverte dans l'ouvrage. Sans qualite de service, la parole telephonique ne peut traverser 
un reseau IP sans dommage. Comme nous le verrons, deux types de qualites de service 
peuvent etre mis en place : soit le flux de la couche application s'adapte au reseau, soit le 
reseau s'adapte a la demande du flux applicatif. 

La premiere solution est la plus ancienne. Elle correspond a une adaptation du flux par 
rapport a un reseau qui reagit en best-effort. Les applications telephoniques telles que 
Skype utilisent cette solution. La seconde solution prend en compte les possibilites du 
reseau en permettant a un flux dont on connait les caracteristiques de traverser le reseau 
dans les meilleures conditions de garantie. La seconde generation d' Internet correspond 
a cette solution. La plupart des offres de telephonie sur IP dans l'entreprise reposent sur 
elle. 



Conclusion 



La telephonie reste une des applications dominantes du monde des reseaux, et ce pour 
encore de nombreuses annees, en raison notamment de 1' emergence de nouveaux et 
immenses marches, comme celui de la Chine. L' application de telephonie ne represente 
plus mi-2008 que 30 % en moyenne du chiffre d'affaires des operateurs, tout en n' occu- 
pant que 4 % du debit total des communications. 

A cette meme date (mi-2008), la TolP mobilise pres de 65 % des debits telephoniques 
dits terrestres (excluant les mobiles). Le passage vers le tout-IP telephonique, permettant 
d'integrer les services de donnees et la telephonie dans un meme reseau, sera effectif vers 
la fin de 2009 en France. 

Cependant, la qualite est tres variable en fonction des efforts effectues par les gestionnaires 
de reseaux d'entreprise et les operateurs de reseaux de telecommunications. Les proble- 
mes a resoudre sont nombreux et parfois complexes. La TolP n'est pas une application 
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simple a mettre en oeuvre dans le contexte de 1' integration de tous les services de tele- 
communications sur le meme reseau. 

La figure 1.16 illustre la place que tiendra la TolP dans les annees a venir. 



Figure 1.16 
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En 2010, pratiquement tout le marche de la telephonie terrestre sera passe en IP. Si Ton 
considere la telephonie hertzienne, sa montee en puissance sera beaucoup plus longue. 
Avec l'UMTS et ses successeurs, le monde de la telephonie hertzienne suit les traces du 
GSM, qui n'est pas une solution IP native. II faudra done attendre 1' extension massive 
des reseaux sans fll IP de types Wi-Fi, WiMax et autres WiMedia et WiRAN avant de 
rejoindre les courbes terrestres. 

II est a noter que l'UMTS apporte une solution de telephonie par paquet mais non-IP. 
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La telephonie sur IP possede les memes contraintes de communication temps reel que la 
telephonie classique. 

Lorsque deux personnes sont l'une en face de l'autre, le temps de transit du signal sortant 
de la bouche d'un utilisateur est quasiment nul. Lorsque les deux personnes sont a 
distance et communiquent par 1' intermediate d'un reseau, la meme contrainte doit etre 
veriflee. Cette contrainte est de 300 ms entre le moment ou le signal sort de la bouche 
jusqu'au moment ou il arrive a l'oreille du destinataire. 

La valeur de 300 ms correspond a une limite superieure. Pour ne pas avoir 1' impression 
que le correspond est situe a l'autre bout de la Terre, un delai de 150 ms est preferable. 
Nous allons detailler cette contrainte du temps de transit, ainsi que les autres contraintes 
qui pesent sur la ToIP. 

Les contraintes temporelles 

La principale difflculte pour realiser de la telephonie par paquet provient de la contrainte 
temporelle tres forte due a l'interaction entre individus. Le temps de latence, c'est-a-dire 
le temps qui s'ecoule entre l'entree d'un paquet dans le reseau et son temps de sortie du 
reseau doit etre inferieur a 300 ms si Ton veut garder une interaction humaine acceptable. 
Si Ton souhaite une bonne qualite de la conversation, il ne faut pas que la latence soit 
superieure a 150 ms. 

Un cas encore plus complexe se produit lorsqu'il y a un echo, c'est-a-dire un signal qui 
revient dans l'oreille de l'emetteur. L'echo qui repart en sens inverse est numerise par un 
codec (codeur/decodeur) et traverse sans probleme un reseau numerique. La valeur 
normalisee de la latence de l'echo etant de 56 ms, pour que l'echo ne soit pas genant a 
l'oreille, il ne faut pas que le temps de transit de la communication depasse 28 ms dans 
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un sens, en supposant un reseau symetrique, demandant le meme temps de transit a Taller 
et au retour. 

Dans les equipements terminaux, les logiciels aux extremites doivent etre capables de 
gerer les retards et de resynchroniser les octets qui se presentent. En regie generale, les 
telephones IP ou les ordinateurs personnels possedent des suppresseurs d'echo evitant 
cette contrainte temporelle forte. 

Le temps de transfert d'un flux de parole telephonique est constitue de la somme des cinq 
temps suivants (voir figure 2.1) : 



Figure 2.1 
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Temps de numerisation de la voix : la parole telephonique est un signal analogique 
impossible a coder sur un ordinateur. II faut la numeriser en donnees numeriques (un 
ensemble de 1 et de 0) a l'aide d'un codec (codeur/decodeur), dont nous expliquerons 
plus loin le fonctionnement. Le temps de numerisation est generalement negligeable, 
mais le codec va determiner la vitesse a laquelle les donnees seront emises. 

Temps de remplissage des paquets : les donnees envoy ees sont assemblies en paquets. 
Ces paquets comportent des en-tetes (avec entre autre l'adresse du recepteur pour 
router le paquet et l'adresse de l'emetteur pour recevoir une reponse), qui sont places 
une fois le paquet constitue. Plus il y a de donnees dans le paquet, moins il y a d' en- 
tetes, et done de consommation de bande passante. En revanche, plus l'attente avant 
d' envoy er le paquet est longue, plus l'interactivite de la communication est compro- 
mise. II est done necessaire d' avoir suffisamment de donnees pour remplir le paquet 
avec une certaine taille avant de l'envoyer dans le reseau. On peut definir le temps de 
remplissage comme le temps mis par le codec pour remplir un paquet de taille fixee 
(cette taille ne prend pas en compte les en-tetes qui sont ajoutes automatiquement et 
independamment du codec). 

Remarquons que nous ne considerons pas le temps que met l'emetteur pour 1' encapsu- 
lation du paquet (avec l'ajout des en-tetes qui correspondent a chaque couche reseau 
traversee, conformement au modele OSI), ni le temps que met le recepteur pour remonter 
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le paquet au niveau du logiciel de telephonie (c'est-a-dire le temps de la decapsulation 
des en-tetes du paquet), qui sont des temps negligeables. 

• Temps de propagation : un signal binaire envoy e d'un endroit arrive a un autre 
endroit apres un certain temps, qui depend de la distance a parcourir. Le temps de 
propagation peut done etre deflni comme le rapport de la distance a parcourir entre 
l'emetteur et le recepteur sur la vitesse de propagation du signal. On prend generalement 
une vitesse de propagation d'un signal de 200 000 km/s. 

• Temps de transmission : des donnees arrivent d'un point a un autre selon un temps 
qui depend de la quantite de donnees emise et du debit auquel fonctionnent les liens 
entre l'emetteur et le recepteur. On peut done deflnir le temps de transmission comme 
le rapport de la quantite de donnees a envoyer sur le debit du lien considere. 

• Temps de traitement par les noeuds intermediaires : pour aller de l'emetteur au 
recepteur, les flux de donnees parcourent un ensemble de routeurs intermediaires qui 
les aiguillent jusqu'a leur source. Chacun de ces noeuds ajoute un delai supplemen- 
taire, qui constitue le temps de traitement des noeuds intermediaires. Ce temps est 
generalement de l'ordre de la milliseconde pour chaque noeud. 

Prenons un exemple pour illustrer 1' ensemble des composants constituant le temps de 
transfert. On considere un reseau de type Ethernet a 100 Mbit/s. L' application logicielle 
de l'emetteur numerise la parole telephonique en un temps negligeable. Elle utilise un 
codeur qui fonctionne a une vitesse de 8 Kbit/s et genere la transmission de paquets 
d'une taille de 64 octets (comprenant 16 octets d'en-tete). Le temps de propagation 
considere est de 200 000 km/s, et la liaison entre l'emetteur et le recepteur comporte 
7 noeuds, chacun traitant un paquet en 1 ms. 

Nous allons chercher la distance maximale D max entre les correspondants pour assurer un 
temps de transfert d'au plus 150 ms. 

Le temps de transfert vaut ainsi : 

T = T + T + T + T + T 

transfert numerisation remplissage propagation transmission traitement_noeud 

Detaillons chacun de ces temps separement : 

Tnumerisation = HIS (neglige) 

T rem P iissage = ( 64 " 16 ) octets/8 Kbit/s = 384 bits/8,10 3 bits = 48 ms 

Tp r opaga ti on = 0^(200 000 km/s) = D max /(200 km/ms) 

transmission = 64 octets/100 Mbit/s = 512 bits/10 8 bits = 0,005 12 ms (negligeable) 

1 traitement_noeud = / X 1 = / HIS 

Pour que le temps de transfert soit inferieur a 150 ms, il faut done que : 

T^sfert = + 48 + D max /200 km + + 7 < 150 
Soit une distance D max de : 



D max < (150 - 55) x 200 = 19 000 km 
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Dans ces conditions, la distance entre l'emetteur et le recepteur doit etre inferieure a 
19 000 km pour assurer un temps de transfert d'au plus 150 ms. 

Le processus de resynchronisation de la parole telephonique 

Du fait de l'interactivite entre deux interlocuteurs, la telephonie IP implique une 
contrainte temporelle de 600 ms (300 ms dans chaque sens). II faut done, apres le trans- 
port des echantillons dans le reseau, les resynchroniser au recepteur de sorte qu'un flot 
regulier soit remis au codec. La difficulte provient du temps de transport asynchrone, 
assez aleatoire, du reseau, qui implique que les paquets sont remis au recepteur a des 
instants quelconques. 

Pour realiser une resynchronisation, il faut memoriser les paquets au recepteur 
pendant un certain temps, appele temps de synchronisation. Pour determiner ce 
temps de synchronisation, on doit au prealable determiner le delai maximal d'attente 
entre le moment de 1' entree du paquet dans le reseau et celui de sa delivrance au 
codec. 

Ce delai doit bien sur etre inferieur a la contrainte temporelle de 1' application. Si 1' appli- 
cation est une telephonie avec echo, il faut choisir une valeur de l'ordre de 15 ms. Si 
1' application est de la telephonie IP de bout en bout, une valeur classique est de l'ordre de 
100 ms. 

Soit D la valeur du delai maximal de traversee du reseau. Le temps de synchronisation est 
defini comme le temps ecoule depuis 1' entree dans le reseau augmente de la valeur D. 
En d'autres termes, entre les temps d'entree et de sortie, il y a un decalage de D. 

Ce processus est illustre a la figure 2.2. 
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Pour realiser un tel algorithme, il faut que le noeud de sortie connaisse les temps d'acces 
dans le reseau afln de pouvoir synchroniser les paquets a ces temps d'acces augmentes du 
delai maximal de traversee. Pour cela, on utilise aux deux extremites des horloges 
synchrones ou dont le synchronisme permet les adjonctions de temps. 

Differents algorithmes de synchronisation sont utilises dans les reseaux qui transportent 
de la parole. lis travaillent soit en synchronisation directe, soit en synchronisation diffe- 
rentielle. Dans le premier cas, les horloges indiquent exactement la meme valeur de 
temps. Dans le second cas, les horloges tournent a la meme vitesse, meme si elles sont 
decalees. On utilise des trames de synchronisation pour determiner la difference entre 
l'horloge d' entree et celle de sortie. 

La telephonie numerique 

Les trois operations successives necessaires a la numerisation de la parole, qu'elle soit 
telephonique ou non, sont les suivantes : 

1. Echantillonnage. Consiste a prendre des points du signal analogique au fur et a 
mesure qu'il se deroule. II est evident que plus la bande passante est importante, 
plus il faut prendre d' echantillons par seconde. C'est le theoreme d' echantillon- 
nage qui donne la solution : il faut echantillonner a une valeur egale a au moins 
deux fois la bande passante. Pour une bande passante de 3 100 Hz, correspondant a 
la bande des 300 a 3 400 Hz, il faut echantillonner au moins 6 200 fois par 
seconde. Si la bande passante est de 20 000 Hz, il faut au moins 40 000 echan- 
tillons par seconde. On comprend ainsi pourquoi la bande passante de la telephonie 
est limitee. 

2. Quantification. Consiste a representer un echantillon par une valeur numerique au 
moyen d'une loi de correspondance. Cette phase consiste a trouver une loi de corres- 
pondance telle que la valeur des signaux ait le plus de signification possible. Cette 
quantification determine la justesse avec laquelle le codage peut s'effectuer. Si le 
codage est sur 7 bits, cela implique 128 niveaux possibles. Plus la largeur de bande 
est importante, plus la longueur du codage doit etre importante. Si Ton reprend 
l'exemple precedent, les 128 niveaux de codage sont equidistribues, mais la parole 
reste essentiellement dans un niveau de frequences situe entre 500 Hz et 1 500 Hz 
sur les 3 100 Hz de bande passante. Les differences entre les echantillons sont relati- 
vement importantes dans la bande des 1 000 Hz, la plus utilisee. Mieux vaut avoir 
des intervalles plus petits sur les frequences fortement utilisees et des intervalles plus 
grands sur les frequences peu utilisees. La loi de correspondance uniforme n'est 
generalement pas la meilleure solution. II faut trouver des lois qui favorisent les 
intervalles de frequences fortement utilises. En regie generale, on utilise des lois 
semi-logarithmiques . 

3. Codage. Consiste a donner une valeur numerique aux echantillons. Ce sont ces 
valeurs qui sont transportees dans les paquets. Dans l'exemple precedent, si Ton 
souhaite determiner 128 intervalles, il faut choisir 7 bits pour le codage. 
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Uechantillonnage 



La largeur de bande de la voix telephonique analogique est de 3 100 Hz. Pour numeriser 
ce signal correctement sans perte de qualite, puisqu'elle est deja relativement mauvaise, 
il faut echantillonner au moins 6 200 fois par seconde. La normalisation a opte pour un 
echantillonnage de 8 000 fois par seconde. 

La quantification s'effectue par des lois semi-logarithmiques. L' amplitude maximale 
permise se trouve divisee en 128 echelons positifs pour la version americaine PCM 
(Pulse Code Modulation), auxquels il faut ajouter 128 echelons negatifs dans la version 
europeenne MIC (modulation, impulsion et codage). Le codage s'effectue done soit sur 
128 valeurs, soit sur 256 valeurs, ce qui demande en binaire 7 ou 8 bits de codage. 

La valeur totale du debit de la numerisation de la parole telephonique s'obtient en multi- 
pliant le nombre d'echantillons par le nombre d' echelons, ce qui donne : 

• 8 000 x 7 bit/s = 56 Kbit/s en Amerique du Nord et au Japon ; 

• 8 000 x 8 bit/s = 64 Kbit/s en Europe. 
La figure 2.3 illustre ce processus. 



Figure 2.3 
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On voit que la numerisation est une approximation : on choisit la valeur de l'echantillon 
la plus proche possible de la valeur reelle. II y a toujours une difference entre la valeur reelle 
et la valeur de l'echantillon choisie sur le quadrillage. En effet, seules les valeurs du 
quadrillage ont une valeur numerique. Lorsque le recepteur re^oit la valeur de l'echan- 
tillon, il considere que e'est la valeur exacte du signal, et il relie les echantillons entre eux 
pour realiser une courbe, qui est en realite constitute d'une succession de droites tirees 
entre deux points. 

Si le nombre d'echantillons est sufflsant, le nouveau signal obtenu est presque identique 
au signal de depart, et la qualite de la parole est maintenue. 
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Les echantillons sont places dans un paquet a la vitesse d'echantillonnage. Dans le cas 
classique, les octets arrivent toutes les 125 jlis. Pour que le temps de reponse de bout en 
bout soit acceptable, il ne faut pas depasser une certaine valeur, qui est generalement 
limitee a 16 ms dans la telephonie sur IP, ce qui represente dans le cas classique 
128 octets. Comme nous allons le voir, cette valeur de 16 ms est beaucoup plus contrai- 
gnante lorsque la parole est compressee puisque le nombre d' octets qui pourront etre 
transposes est beaucoup plus faible. 

La perte d'un echantillon de temps en temps n'est pas grave. II suffit de remplacer 1' octet 
manquant par un octet estime a partir du precedent et du suivant. La perte d'un paquet 
n'est pas non plus catastrophique, puisque le temps perdu n'est que de quelques milli- 
secondes. 

La figure 2.4 illustre le cas ou un paquet contenant 10 echantillons est perdu. Pour avoir 
une courbe continue, on relie le dernier echantillon re^u au premier de la trame re^ue. 
Avec cette solution, l'oreille ne peut detecter la perte du paquet, sachant que meme dans 
le cas d'une assez forte compression de la parole, par exemple a 8 Kbit/s, cela ne repre- 
sente que 10ms. 



Figure 2.4 
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La perte d'un paquet doit cependant etre detectee. En effet, le risque serait qu'un paquet 
soit perdu et que le recepteur, a la reception du paquet suivant, recolle le premier octet de 
ce nouveau paquet juste apres le dernier octet du precedent (voir figure 2.5). 

Dans ce cas, le signal reforme peut changer de frequence brutalement, s'accompagnant 
d'un bruit genant pour l'oreille. II faut done detecter la perte d'un paquet, par exemple 
par une numerotation reguliere des paquets, et laisser un intervalle correspondant a la 
longueur du paquet qui sera rempli par une droite reliant le dernier octet bien re^u au 
premier octet du paquet arrive apres le paquet perdu. C'est la droite en pointilles illustree 
a la figure 2.4. 
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II est a noter qu'un algorithme astucieux pourrait approximer beaucoup mieux qu'une 
droite le signal entre ces deux points en tenant compte des pentes du signal aux deux 
octets ajoindre. 



Figure 2.5 
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Techniques de codage 

II est possible de compresser la parole numerisee par differentes techniques. La plus clas- 
sique d' entre elles est le codage differentiel, qui consiste a travailler sur les differences 
entre les echantillons plutot que d'effectuer un codage absolu, comme dans le cas 
presente precedemment, ou chaque point etait code independamment du point precedent 
ou du point suivant. 

Le codage differentiel permet de compresser le flot de donnees. Au lieu de coder la valeur 
complete de l'echantillon, on ne transmet que la difference avec l'echantillon precedent. 
Comme le nombre d' echantillons est important toutes les secondes, la difference entre 
deux echantillons est generalement tres petite. 

Un exemple de codage differentiel est illustre a la figure 2.6. Le codage de la difference 
demande moins d' elements binaires que le codage complet d'un echantillon. Chaque fois 
qu'une difference est transmise, on effectue une approximation puisque la valeur d'un 
echantillon est codee par la meilleure valeur possible, mais qui n'est pas exacte. De ce 
fait, on accumule les approximations. Au bout de quelques dizaines d' echantillons, la 
valeur peut devenir fortement erronee. 

C'est la raison pour laquelle il faut envoyer a intervalle regulier une valeur complete d'un 
echantillon pour continuer la transmission. On peut en conclure que la compression genere un 
flot variable dans le temps : regulierement, on a un codage complet de l'echantillon (sur 8 bits 
pour la parole telephonique), puis, entre deux valeurs completes, les echantillons ne 
demandent plus que 3 ou 4 bits de codage, ce qui permet de diminuer le debit. 

Parmi les autres techniques de numerisation de la parole, signalons celles qui consistent 
a travailler en temps reel ou en temps differe. Dans le premier cas, 1' algorithme qui 
permet de traduire la loi intermediaire de quantification doit etre execute en temps reel. 
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Figure 2.6 
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Les elements binaires obtenus ne sont pas compresses, ou tres peu. Dans le second cas, la 
parole peut etre stockee sur des volumes beaucoup plus faibles, mais le temps necessaire 
pour effectuer la decompression est trop long pour regenerer un flot synchrone d' octets, 
et done le signal analogique de sortie. II faut une memorisation intermediate qui 
supprime le caractere temps reel de la parole. Pour les messageries numeriques, une 
compression est presque toujours effectuee afin que les capacites de stockage ne soient 
pas trop sollicitees. Dans ce cas, on descend a des debits inferieurs a 2 Kbit/s. 



Figure 2.7 
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On peut citer parmi les techniques temps reel les methodes A (Delta) ou A M (Delta 
Modulation), qui s'appuient sur le codage d'un echantillon en relation avec le precedent. 
Par exemple, on peut deflnir le point d'echantillonnage k + 1 par la pente de la droite 
reliant les echantillons k et k+ 1, comme illustre a la figure 2.7. On envoie la valeur 
exacte du premier echantillon, puis on ne transmet que les pentes. Etant donne que la 
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pente de la droite ne donne qu'une approximation du point suivant, il faut regulierement 
emettre un nouvel echantillon avec sa valeur exacte. 

Grace a ces methodes, le debit de la parole numerique peut descendre a 32, 16 ou 8 Kbit/s, 
voire moins. Si Ton descend jusqu'a 2 Kbit/s, on obtient une parole synthetique, de 
mediocre qualite. Nous n'avons pris pour exemple jusqu'ici que la parole numerique. 
II va de soi que toutes les informations analogiques peuvent etre numerisees de la meme 
fa^on. 

Bien d'autres solutions que celles que nous venons de voir ont ete developpees pour 
compresser la parole telephonique en utilisant les qualites et les defauts de l'oreille : 

• AD-PCM (Adaptive Differential-Pulse Code Modulation), ou modulation par impulsion 
et codage differentiel adaptatif ; 

• SBC (Sub-Band Coding) ; 

• LPC (Linear Predictive Coding) ; 

• CELP (Code Excited Linear Prediction). 

De nombreuses extensions pour obtenir une meilleure qualite de la telephonie ont ete 
proposees et experimentees. La plupart concernent l'elargissement de la partie du spectre 
utilisee pour le codage. L' extension la plus classique permet de coder la parole entre 
50 et 7 000 Hz, ce qui donne une bande passante de 6 950 Hz a la place des 3 100 Hz 
standards. 

Les codeurs audio 

De nombreux codeurs audio sont associes aux differentes techniques detaillees prece- 
demment. On trouve notamment les codecs classiques mais aussi de nouveaux codeurs 
bas debit. On peut classer les codecs en trois grandes classes : 

• codeurs en forme d'ondes utilisant l'onde sans compression ; 

• codeurs parametriques utilisant un modele de production vocale ; 

• codeurs hybrides combinant les deux precedents. 

Selon ces differentes classes, il existe plusieurs sortes de codecs : 

• Codecs PCM (Pulse Code Modulation), les premiers a etre apparus, fonctionnant a un 
debit fixe. 

• Codecs AD-PCM (Adaptative Differential-Pulse Code Modulation) fonctionnant a des 
debits variables s'adaptant au debit de la liaison ou du reseau. Les debits les plus 
classiques sont de 32, 24 ou 16 Kbit/s. 

• Codecs adaptes aux reseaux de mobiles, comme le GSM-EFR (Enhanced Full Rate), 
normalise par l'ETSI sous la recommandation GSM 06.60 en 1996 ou encore adapte a 
l'UMTS. 

• Codecs Internet, comme le CELP (Code Excited Linear Prediction). 
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Pour 1' audio haute definition, on considere une bande passante plus importante puisque 
l'oreille humaine est sensible aux frequences de 20 a 20 000 Hz. L'echantillonnage 
s'effectue sur 40 kHz, et c'est la valeur de 44,1 kHz qui a ete choisie. Le codage effectue 
sur un CD tient sur 16 bits par echantillon, ce qui donne 705,6 Kbit/s. Cependant, il 
existe de nombreuses solutions, certaines normalisees et d'autres proprietaires. 

Dans le domaine normalise, on peut citer AMR-WB (Adaptative Multi-Rate- WideB and) 
de l'UIT-T (Recommandation G.722.2), datant de 2002. 

Parmi les nombreux codeurs proprietaires du marche, citons notamment les suivants : 

• StreamWorks a 8,5 Kbit/s ; 

• Vox Ware a 2,4 Kbit/s avec le codeur RT24 ; 

• Microsoft a 5,3 Kbit/s avec une utilisation partielle de la norme G.723 ; 

• VocalTec a 7,7 Kbit/s. 

La figure 2.8 illustre les performances des differentes normes de codeurs de la voix tele- 
phonique en termes de qualite et de debit, en se fondant sur un echantillonnage standard 
a 8 kHz. L'ordonnee represente la qualite du son en reception. II s'agit evidemment d'un 
critere subjectif, mais qui peut etre calcule mathematiquement, comme nous le verrons. 
Nous avons aussi represente les codeurs utilises dans les reseaux de mobiles GSM et les 
normes regionales. 



Figure 2.8 
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Les principales recommandations illustrees sur la figure sont les suivantes : 

• G.711 : numerisation classique a 64 Kbit/s en Europe ou 56 Kbit/s en Amerique du 
Nord. 
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• G.723 : compression de la parole utilisee par de nombreux industriels, entre autres 
Microsoft, dans l'environnement Windows. Le debit descend a presque 5 Kbit/s. 

• G.726 : compression de la parole en codage differentiel adaptatif en 16, 24, 32 ou 
40 Kbit/s. 

• G.727 : utilise aussi un codage differentiel, mais apporte des complements au codage 
precedent. Cette recommandation indique comment changer, en cours de numeri- 
sation, le nombre de bits utilises pour coder les echantillons. Elle est particulierement 
utile dans le cadre de reseaux demandant a 1' application de s' adapter a sa charge. 

• G.728 : compression a 16 Kbit/s utilisant une technique de prediction, qui consiste a 
coder la difference entre la valeur reelle et une valeur estimee de l'echantillon a partir 
des echantillons precedents. On comprend que cette difference puisse etre encore plus 
petite que dans la technique differentielle. Si 1' estimation est bonne, la valeur a trans- 
porter avoisine toujours 0. Tres peu de bits sont alors necessaires pour acheminer cette 
difference. 

• FS : standards provenant du departement de la Defense americain (DOD). 

• G.723. 1 : donne un debit compris entre 5,3 et 6,4 Kbit/s. 

• G.729 et G.729 A : donnent un debit de 8 Kbit/s, mais la qualite de la communication 
est meilleure. Ces codecs ont ete choisis pour compresser la voix dans l'UMTS. 

Les codeurs les plus recents sont G.723. 1, G.729 et G.729.A. 

Le tableau 2.1 recapitule les caracteristiques de ces codeurs. 

Tableau 2.1 - Caracteristiques des principaux codeurs 



Standard 


G.711 


G.729 ( 2 ) 


G.723.1 W( 2 ) 


GSM ( 3 ) 

06.10(1988) 


GSM 

06.60(1996) 


DOD 1016 ( 2 ) 


Debit (Kbit/s) 


64 


8 


6,3/5,3 


13 


12,2 


4,8 


Complex. MIPS 


0,1 


22 


16/18 


2,5 


15,4 


- 


Trame (ms) 


0,125 


10 


30 


20 


20 


- 


Qualite MOS ] 


4,2 


4,0 


3,9/3,7 


3,6/3,8 


4,1 


3 



(1) MOS (Mean Opinion Scores) 

(2) CELP (Code Excited Linear Predictive) 

(3) RLP-LTP (Regular Pulse Excited with Long Term Prediction) 

(4) MP-MLQ (MultiPulse-Maximum Likelihood Quantization) 

Dans ce tableau, nous avons indique, en plus du debit qui sort du codec, la complexite du 
processeur (deuxieme ligne) necessaire pour effectuer les calculs lors de la decompres- 
sion, qui demande generalement davantage de puissance que la compression. On voit 
bien que le codage classique G.711 est de loin le plus simple puisqu'il n'y a pas de 
compression. 
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La troisieme ligne indique la longueur de la trame. Dans le cas de G.71 1, on peut consi- 
derer que cette solution n' a jamais vraiment ete utilisee pour du transfert de paquets mais 
seulement pour de la commutation de circuits, ou les octets sont envoyes immediatement. 
On peut de ce fait considerer que la trame a une longueur d'un octet et que remission 
d'une trame s'effectue toutes les 125 us. 

Pour le codage G.729, le debit de sortie moyen etant de 1 octet toutes les millisecondes, 
il y a en moyenne 10 octets dans la trame. Cependant, a certains instants, le debit peut- 
etre legerement plus important. Dans ce cas, la trame de 10 ms peut transporter jusqu' a 
16 octets. Dans d'autre cas, la trame peut transporter moins de 10 octets. 

La derniere ligne du tableau indique la valeur MOS (Mean Opinion Score). Cette valeur 
correspond a 1' opinion de personnes appelees a ecouter les differentes sortes de voix 
compressees et a s'en former une opinion. Ce n'est que depuis quelques annees qu'un 
calcul mathematique de cette valeur a pu etre realise en ne considerant que les caracteris- 
tiques de la communication. Le MOS calcule est une norme de l'ETSI et de l'UIT-T. 



Qualite de service de la TolP 

Nous avons deja aborde un certain nombre de caracteristiques permettant de definir la 
qualite de la parole telephonique. Nous allons les approfondir dans cette section. 

D'une maniere generale, on retient trois facteurs pour determiner la qualite de service 
d'une application de telephonie : 

• Qualite de la transmission de la voix. C'est la partie technique qui prend en compte 
le signal de depart et qui essaie de le retranscrire au mieux au niveau du recepteur. 

• Efficacite de la conversation. C'est l'interactivite plus ou moins grande entre les deux 
individus en train de converser. 

• Intelligibilite de la communication. C'est la fa^on dont s'expriment les individus en 
communication. 

Ce dernier facteur ne depend que des individus qui parlent, mais 1' impact des deux 
premiers facteurs est important sur le troisieme. Si 1' intelligibilite est faible et qu'en plus 
la qualite de la transmission et 1' efficacite de la conversation sont mauvaises, il y a de 
fortes chances que les paroles ne soient pas comprises. 

Dans le premier critere, il faut retenir surtout la bande passante utilisee et la retranscrip- 
tion plus ou moins bonne en fonction des codecs et des taux de perte de paquets. Dans le 
deuxieme, c'est le temps de reponse qui donne une conversation plus ou moins hachee. 
Le troisieme critere depend de la prononciation des personnes en communication. Avec 
une bande etroite de 3 100 Hz, il est difficile de differencier un « s » d'un « f ». Si Ton 
augmente a 6 950 Hz de bande passante la differentiation est beaucoup plus aisee. 

Des facteurs externes sont egalement a prendre en compte dans la qualite perdue. 
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Les principaux facteurs externes sont les suivants : 

• Bruit de ligne de la communication. 

• Bruit correle au signal qui provient generalement du codec et essentiellement du choix 
de la quantification. 

• Bruit de fond provenant de l'endroit ou se trouve le micro. 

II est done tres difficile d'evaluer la qualite de la voix en dehors d'une ecoute d'un utili- 
sateur, qui est capable de prendre en compte 1' ensemble des parametres importants, d'ou 
l'origine de la technique MOS (Mean Opinion Score). 

Le type de test le plus utilise dans cette evaluation subjective de la qualite telephonique 
est le test ACR (Absolute Category Rating). Cette recommandation de l'UIT-T datant de 
1996 (reference R800) utilise une echelle notee sur 5 points, avec ou sans annotations, 
appelee echelle MOS. 

Les valeurs de cette echelle de qualite sont recapitulees au tableau 2.2. 
Tableau 2.2 - Echelle de qualite du test MOS 

Excellente Bonne Correcte Faible Mauvaise 

5 4 3 2 1 

L' inconvenient de cette solution est evidemment sa subjectivite. Les organismes interna- 
tionaux de normalisation se sont penches depuis longtemps sur 1' evaluation de la qualite, 
et differentes approches ont ete proposees avant d'aboutir a un calcul mathematique du 
facteurMOS. 

Le premier modele propose par l'UIT-T, le modele E, estime la qualite globale du 
sy steme grace a des mesures instrumentales et a une description du systeme a l'aide de 
nombreux parametres. Ce modele provient de l'integration de plusieurs modeles de l'ETSI 
dans une norme de 1996, appelee ETSI ETR 250. Cette norme a ete reprise au niveau 
international par l'UIT-T pour deflnir en 2005 la qualite de la parole telephonique dans 
un reseau sous la recommandation G.107. 

Cette recommandation s'appuie sur le fait que les degradations s'ajoutent les unes aux 
autres sur une echelle de qualite predeterminee. Si un signal traverse plusieurs equipements, 
les degradations des equipements s'additionnent. 

L' echelle de qualite R peut ainsi s'exprimer sous la forme : 

R = Ro - Is - Id - Ie,eff + A 

ou 

• Ro represente le rapport signal sur bruit par rapport au point dB, en prenant en 
compte le niveau de la voix et les differents bruits presents sur la ligne. 

• Is represente la degradation qui s'effectue sur la parole elle-meme. 
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• Id represente la degradation provenant du delai ou de l'echo. 

• Ie,eff represente la degradation de la qualite de la parole subie pendant la transmission 
au travers d'un ou de plusieurs codecs. Les pertes de paquets peuvent etre prises ou 
non en compte dans ce parametre. 

• A represente un parametre dont l'objectif est de determiner les avantages a utiliser la 
parole numerisee. Ce parametre a essentiellement ete ajoute pour tenir compte de 
la mobilite des telephones, ce qui represente un avantage important par rapport a la 
qualite intrinseque de la voix et qui fait penser au client qu'une qualite plus mediocre 
est aussi bonne qu'une qualite meilleure mais sur un telephone fixe. 

L'echelle R est comprise entre et 100, ou correspond a la plus mauvaise qualite et 100 
a la meilleure. La valeur R de la reference de la telephonie bande etroite (G.711 sur 
l'echelle) utilisee sur un canal sans bruit vaut : 

R = 93,2 

Pour obtenir la valeur MOS equivalente, l'UIT-T a introduit la formule : 

[ 1 [ pour :R<0 

MOS = 1 1 + 0,035 *R + R(R- 60)(100 -R)* 7.10~ 6 J pour : < R < 100 
{ 4,5 { pour : R < 100 

De plus en plus de systemes utilisent ce calcul pour determiner si la parole telephonique 
passe correctement ou non. Si la valeur MOS est trop faible, le systeme applique un 
controle sur les flux qui ne sont pas de la parole telephonique jusqu'a ce que le MOS 
remonte a une valeur acceptable. De meme, de nombreux reseaux testent en permanence 
la valeur MOS sur des paquets de controle afin de determiner si le reseau est apte a vehi- 
culer de la parole telephonique. 

Caracteristiques du debit 

Les octets qui sortent du codec donnent une premiere estimation de la valeur du debit, 
qui ne tient compte que du flux de parole. Cependant, ce qui transite dans le reseau est 
bien different : il faut envelopper les octets de parole dans un paquet, un paquet IP en 
general, puis encapsuler le paquet IP dans une trame. De plus, il faut une signalisation 
pour mettre en place le mode connecte correspondant au declenchement de la sonnerie 
chez le destinataire. Enfin, une signalisation peut etre ajoutee afin d'ouvrir le chemin par 
lequel transiteront les paquets de paroles. 

Le debit total est done bien superieur a celui de la seule voix telephonique. 

Le tableau 2.3 indique l'efficacite de la communication lorsque la paquetisation s'effectue 
dans un paquet IPv4, en negligeant dans un premier temps la trame utilisee. 

Dans cette premiere evaluation, nous supposons que la zone de donnees est complete- 
ment remplie par des octets de parole. Cette zone de donnees est encapsulee dans un 
paquet IPv4. Les calculs s'effectuent pour differentes durees de la zone de donnees : 5, 
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10, 20 et 40 ms. Cela demande un temps de remplissage dependant de la vitesse du 
codec. 

Le tableau indique en pourcentage l'efficacite de la communication, c'est-a-dire la 
proportion d' octets telephoniques transitant sur la voie de communication par 
rapport a l'ensemble des bits transmis. Suivant la structure des options d'IPv4, nous 
avons calcule le maximum et le minimum d' efficacite, le maximum etant obtenu 
lorsque le paquet IPv4 est le plus petit possible et le minimum lorsqu'il est le plus 
long possible. 

Tableau 2.3 - Efficacite d'une communication deTolP (IPv4) 





Temps de remplissage de la zone 


de donnees (en milliseconde) 




Codec 


5 


10 


20 


40 


G.711 


47,6 % 


64,5 % 


78,4 % 


87,9 % 


G.711 


38,5 % 


55,6 % 


71 ,4 % 


83,3 % 


G.726 


31,3% 


47,6 % 


64,5 % 


78,4 % 


G.726 


23,8 % 


38,5 % 


55,6 % 


71,4% 


G.729 


10,2% 


18,5% 


313,3% 


47,6 % 


G.729 


7,2 % 


13,5% 


23,8 % 


38,5 % 



Plus le codec donne naissance a un flot compresse, plus 1' efficacite est faible, puisque 
plus le nombre d' octets utiles dans le paquet est faible. De meme, plus le temps de 
remplissage est faible, plus l'efficacite diminue. 

Une autre fa^on de raisonner consiste a determiner le flux reel d'une communication de 
telephonie sur IP. Ce flux permet d'evaluer le debit des liaisons dont une entreprise a 
besoin pour y integrer un systeme de telephonie ou qu'un operateur doit mettre en place 
en fonction du nombre de paroles telephoniques devant transiter dans son reseau. 

Le tableau 2.4 donne une premiere evaluation de ces debits, toujours en calculant dans 
chaque cas le maximum et le minimum que peut procurer IPv4. 

Tableau 2.4 - Debits reels lors d'une communication deTolP (IPv4) 



Codec 


Algorithme 
de codage 


Debit de la parole 
telephonique 


Duree de remplissage 
de la zone de donnees 


Debit reel 


G.711 


PCM 


64 Kbit/s 




0,125 ms 


80 Kbit/s 


G.723.1 


ACELP 


5,6 Kbit/s 




30 ms 


16,27 Kbit/s 


G.723.1 


ACELP 


6,4 Kbit/s 




30 ms 


17,07 Kbit/s 


G.726 


ADPCM 


32 Kbit/s 




0,125 ms 


48 Kbit/s 


G.728 


LD-CELP 


16 Kbit/s 




0,625 ms 


32 Kbit/s 


G.729(A) 


CS-CELP 


8 Kbit/s 




10 ms 


24 Kbit/s 
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Si Ton tient compte de la structure de la trame, c'est-a-dire des octets de supervision 
supplementaires necessaires pour transporter les informations de telephonie, le debit 
necessaire pour transporter la parole telephonique augmente. 

Le tableau 2.5 donne une idee de l'efflcacite de reseaux Ethernet a 10-100 Mbit/s et 

I Gbit/s et d'un reseau ATM. 

II faut bien differencier les deux types de reseaux Ethernet, car la longueur minimale de 
la trame est differente : 64 octets dans le premier cas et 512 octets dans le second. 

En ce qui concerne ATM, la trame est de longueur constante et contient 48 octets de 
donnees et 5 octets de supervision. On suppose dans notre calcul que les 48 octets de donnees 
transportent le paquet IP, qui, de ce fait, doit etre decoupe en plusieurs fragments pour 
etre encapsule dans des trames ATM. Nous utilisons pour ce faire, la couche AAL5 (ATM 
Adaptation Layer). D'autres options sont possibles dans le monde ATM, notamment 
AAL1 et AAL2, mais, dans ces deux cas, il n'y a pas de paquet IP encapsule. Les octets 
telephoniques sont directement mis dans la trame ATM en AAL1, et les octets de plusieurs 
voix telephoniques peuvent etre multiplexes dans une meme trame ATM en AAL2. 

Le tableau restreint les calculs aux cas ou IPv4 est utilise avec le plus d' options. 
Tableau 2.5 - Eff icacite des reseaux Ethernet et ATM (IPv4) 

Temps de remplissage de la zone de donnees en milliseconde 



Codec 


5 


10 


20 


40 


G.711, Ethernet 10-100 Mbit/s 


0,31 


0,48 


0,65 


0,78 


G.711, Ethernet 1 Gbit/s 


0,08 


0,16 


0,31 


0,62 


G.711, ATM 


0,25 


0,91 


0,60 


0,91 


G.726, Ethernet 10-100 Mbit/s 


0,19 


0,31 


0,48 


0,65 


G.726, Ethernet 1 Gbit/s 


0,04 


0,08 


0,16 


0,31 


G.726, ATM 


0,13 


0,25 


0,55 


0,60 


G.729, Ethernet 10-100 Mbit/s 


0,08 


0,15 


0,27 


0,42 


G.729, Ethernet 1 Gbit/s 


0,02 


0,03 


0,06 


0,12 


G.729, ATM 


0,08 


0,16 


0,30 


0,30 



Le tableau illustre la tres mauvaise utilisation generale du support physique pour une 
communication de telephonie sur IP. II merite cependant quelques explications, etant 
donne que les valeurs indiquees ne semblent pas homogenes. 

Tout d'abord, les mauvais resultats de 1' Ethernet GbE (1 Gbit/s) proviennent de la trame 
minimale, qui est de 512 octets. Meme pour transporter 8 octets, comme c'est le cas avec 
le codeur G.729, pour une zone de donnees de 5 ms, il faut 512 octets de trame Ethernet. 
II est evident qu'une solution pour augmenter l'efficacite consisterait a multiplexer 
plusieurs paroles telephoniques dans une meme trame ou a multiplexer la parole 
telephonique avec d'autres applications. Ce n'est pour le moment que tres peu usite, car 
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il n'y a aucune normalisation d'un tel multiplexage. Les techniques de cette sorte restent 
encore aujourd'hui proprietaries. 

Les resultats sont encore plus hieratiques pour le transport par une trame ATM. En effet, 
les trames etant de longueur constante, si la longueur du paquet IP n'est pas un multiple 
de 48 octets, le paquet doit etre divise en plusieurs morceaux de 48 octets, le dernier frag- 
ment faisant moins de 48 octets. Suivant que Ton tombe sur un multiple de 48 octets et 
que Ton utilise plus ou moins de trames, l'efflcacite varie du tout au tout. 

Le tableau 2.6 indique les valeurs des flux correspondant a ces differents cas de figure. 
Tableau 2.6 - Debits reels des reseaux Ethernet et ATM (IPv4) 

Temps de remplissage de la zone de donnees en milliseconde 



Codec 


5 


10 


20 


40 


G.711, Ethernet 10-100 Mbit/s 


206 


133 


74 


82 


G.711, Ethernet 1 Gbit/s 


832 


416 


208 


104 


G.711, ATM 


256 


70 


107 


70 


G.726, Ethernet 10-100 Mbit/s 


168 


103 


67 


49 


G.726, Ethernet 1 Gbit/s 


768 


384 


192 


96 


G.726, ATM 


246 


128 


58 


53 


G.729, Ethernet 10-100 Mbit/s 


100 


53 


30 


15 


G.729, Ethernet 1 Gbit/s 


400 


266 


133 


67 


G.729, ATM 


100 


50 


27 


27 



On remarque que la telephonie sur IP occupe une bande passante assez importante. II est 
vivement deconseille de choisir un reseau GbE pour y effectuer de la telephonie seule, 
puisque le nombre de paroles telephoniques pouvant transiter sur une liaison est le meme 
que pour un reseau Ethernet a 100 Mbit/s, celui-ci valant aujourd'hui cinq fois moins 
cher. 

Pour faire diminuer le trafic reel, il faut que la zone de donnees du paquet soit la plus 
longue possible, sauf en ATM, du fait du decoupage complexe des paquets dans les 
trames. Un compromis est a trouver entre une zone de donnees assez longue pour optimi- 
ser l'efflcacite et le temps de paquetisation, qui, s'il devient trop long, sera inacceptable 
pour la communication. 

Nous revenons sur cette problematique a la section suivante. 



Le controle dans la TolP 

Comme indique en debut de chapitre, la telephonie sur IP est une application temps reel 
qui n'accepte qu'un temps de reponse inferieur a 300 ms. Dans 1' Internet de premiere 
generation, le reseau ne doit pas etre trop charge pour que cette contrainte soit respectee. 
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Dans les reseaux d'entreprise et ceux des fournisseurs d'acces a Internet et des opera- 
teurs, le passage de la parole est possible a condition de controler le reseau afln que le 
temps total de transport, y compris la paquetisation et la depaquetisation, soit limite. 

De nombreuses solutions ont ete proposees, notamment par 1'IMTC (International Multi- 
media Teleconferencing Consortium). II a d'abord fallu definir un codeur normalise. Le 
choix s'est porte sur G.723, mais d'autres solutions sont possibles, comme le codeur 
G.711. 

Le paquet IP doit non seulement etre le plus court possible, mais il doit multiplexer 
plusieurs voies de parole dans un meme paquet, afln de raccourcir le temps de remplissage 
et de limiter les temps de transfert dans le reseau. Si les routeurs peuvent gerer des priorites, 
ce qui est possible en utilisant des services de type DiffServ, la parole telephonique est 
acheminee beaucoup plus facilement dans le laps de temps exige. 

Plusieurs organismes de normalisation de droit ou de fait travaillent sur ce sujet parti- 
culierement prometteur. Dans les organismes de droit, l'ETSI, l'organisme de normali- 
sation europeen, a mis sur pied le groupe TIPHON (Telecommunications and Internet 
Protocol Harmonization Over Networks). Le projet porte sur la parole et le fax entre utilisa- 
teurs connectes, en particulier sur des reseaux IP. Le cas ou un utilisateur travaille sur un 
reseau IP et un autre sur un reseau a commutation de circuits, qu'il soit telephonique, 
GSM ou UMTS, entre egalement dans le cadre des etudes de TIPHON. 

Les activites de TIPHON concernent egalement la validation des solutions pour transpor- 
ter la parole telephonique par le biais de maquettes en vraie grandeur. II s'agit d' expe- 
riences menees conjointement par l'ETSI, l'UIT-T et 1'IETF mais aussi avec les groupes 
IMTC et VoIP (Voice over IP). 

L'UIT-T travaille de son cote activement a la normalisation de la TolP dans trois groupes 
du SG 16 : le WP1 pour les modems (serie V), le WP2 pour les codecs (serie G) et le 
WP3 pour les terminaux (serie H). L'objectif de l'UIT-T est de developper un environnement 
complet, et non simplement un terminal ou un protocole. 

Au sein de 1TETF, de nombreux groupes de travail s'attaquent a des problemes speciflques, 
parmi lesquels : 

• AVT (Audio Video Transport), qui utilise le protocole RTP (RFC 1889 et 1890) pour 
les communications temps reel. 

• MMUSIC (Multiparty Multimedia Session Control), qui utilise le protocole SIP, que 
nous introduisons plus loin. 

• IPTel (IP Telephony), qui deflnit un protocole de localisation des passerelles et un 
langage permettant de mettre en communication des circuits et des flots IP. 

• PINT (PSTN IP Internetworking), qui utilise egalement le protocole SIP. 

• FAX (Fax over IP), afln de stocker et emettre des fax par l'intermediaire de messages 
electroniques. 
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• MeGaCo (Media Gateway Control), qui determine un protocole entre une passerelle et 
son controleur. 

• SIGTRAN (Signal Translation), qui propose de passer les commandes de signalisation 
CCITT n° 7 dans des paquets IP. 

• ENUM (E.164/IP translations), qui gere les translations d'adresses E.164 vers des 
adresses IP. 

Le respect de la contrainte temporelle est une premiere priorite pour le transport de la 
parole telephonique. Une seconde priorite concerne la mise en place d'une signalisation 
afln de mettre en connexion les deux utilisateurs qui veulent se parler. 

Les protocoles de signalisation utilises pour le transport et la gestion de la parole sous 
forme de paquets IP regroupent essentiellement H.323 et SIP (Session Initiation Proto- 
col). Nous verrons en detail le protocole H.323 au chapitre suivant. Ce protocole a ete 
defini dans un environnement de telecommunications, a la difference de SIP, qui provient 
du monde de l'informatique et plus specifiquement du Web. SIP peut utiliser le protocole 
HTTP ainsi que la securite afferente. II peut en outre s'accommoder des pare-feu. SIP 
met en place des sessions, qui ne sont que des appels telephoniques entre un client et un 
serveur. Six primitives HTTP sont utilisees pour cela : invite, bye, options, ack, register 
et CANCEL. 



Conclusion 



Nous avons introduit dans ce chapitre les principales contraintes de la telephonie sur IP. 
La complexity de cette derniere, fortement accrue par rapport a la telephonie classique 
sur circuit, est le prix a payer pour passer a l'integration de la telephonie dans le monde 
plus vaste des donnees. 

On peut en deduire que le cout d' installation d'un reseau de telephonie sur IP est relati- 
vement important puisqu'il faut mettre en place tout un nouvel environnement, incluant 
des terminaux de type telephone IP ou PC, un systeme de signalisation pour mettre en 
place les connexions et un controle du reseau pour que les temps de reponse restent 
faibles. La rentabilite d'un tel environnement n'est possible que sur plusieurs annees. 

D'autres contraintes, telles que la securite, la disponibilite ou l'utilisation des techniques 
P2P, sont abordees dans la suite de l'ouvrage. 
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La signalisation H.323 



La signalisation designe la transmission d'un ensemble de signaux et d' informations de 
controle echanges entre les intervenants d'une communication. Ces intervenants peuvent 
etre des entites en bout de liaison (terminaux) ou des entites intermediaries de controle et 
de gestion des communications. Leurs echanges permettent l'initiation, la negotiation, 
l'etablissement, le maintien et la fermeture de la connexion. 

II convient de distinguer deux types de transferts pour comprendre a quoi correspond la 
signalisation : 

• le transfert de donnees brutes ; 

• le transfert d' informations de controle. 

Le transfert de donnees brutes concerne les echanges de donnees binaires d'un poste vers 
un autre. L'objectif de ce transfert est de reproduire a l'identique des donnees en les 
faisant transiter par un reseau. Par exemple, deux correspondants peuvent s'echanger un 
fichier audio MP3 ou des images bitmap, comme a la figure 3.1, ou l'utilisateur Alain 
envoie des donnees vers le poste de Beatrice. 



Figure 3.1 
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De la meme fa^on, si Ton considere une conversation telephonique en cours, les inter- 
venants produisent des sons qui doivent etre recomposes et diffuses chez leurs corres- 
pondants. 

Dans tous ces cas, seul l'envoi des donnees a de rimportance, ce qui releve d'un transport 
d' informations. 

Le transfert d' informations de controle concerne les echanges de type protocolaire 
executant une action predefinie, et done necessairement limitee en possibilites. L'objectif 
de ce transfert est d' assurer la maitrise et la gestion du flux. 

Dans le cas typique d'une application de telephonie, lorsqu'une personne en appelle une 
autre, elle n'a initialement pas de « donnees » a lui transmettre, mais veut simplement 
etre mise en relation avec son correspondant. Cette mise en relation necessite d'abord de 
localiser l'appele, puis de faire sonner son poste, afin de lui signaler l'appel. Pour la loca- 
lisation comme pour l'avertissement d'appel, on parle de signalisation. 

La figure 3.2 illustre quelques exemples de messages de signalisation transportant des 
requetes et reponses a caractere descriptif . 



Figure 3.2 
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De la meme maniere, lorsque la sonnerie d'appel retentit dans le terminal appele, 1' appe- 
lant en est immediatement informe par une tonalite particuliere sur son terminal tele- 
phonique. II s'agit la aussi d'une information de signalisation. 

Si un correspondant ne repond pas a un appel, il est probable que sa messagerie tele- 
phonique va s'enclencher. Cette redirection d'appel du poste appele vers sa messagerie 
est egalement une information de signalisation. Elle ne transporte aucune information de 
donnees brutes, mais vise a signaler a 1' appelant que 1' appele n'est pas disponible et que 
sa messagerie est operationnelle. 

Ces deux categories de transfert sont liees : ce n'est que lorsque 1' appele a repondu a 
l'appel que commence le transfert d' informations brutes, c'est-a-dire le transport de la 
voix, qui doit etre fidelement retransmise d'un correspondant a 1' autre. La signalisation 
n'est que l'etape prealable qui a mis en place la connexion entre les differents utilisateurs 
pour permettre la communication. 

Dans le modele OSI, la signalisation telephonique correspond a une fonctionnalite de 
niveau 7 (couche applicative). Elle n'est done jamais assuree par les entites reseau de routage 
pur, comme les routeurs et commutateurs, qui fonctionnent a des couches inferieures. 
Des entites dediees sont exploitees a ces fins : il s'agit de serveurs au niveau du cceur du 
reseau et des terminaux (telephone, ordinateur ou PDA, par exemple) en bordure de reseau, 
au niveau de l'utilisateur. 

Pour etre comprise et correctement interpretee de 1' ensemble des entites participant aux 
mecanismes de signalisation, celle-ci doit respecter une syntaxe particuliere. C'est tout 
l'objet de la specification d'un protocole de signalisation. 

Le protocole H.323 figure parmi les plus reputes des protocoles de signalisation pour la 
telephonie sur IP. H.323 n'est en realite que la reference du protocole. Son nom complet 
est Packet-based Multimedia Communications Systems, ou « Systemes de communica- 
tion multimedia fonctionnant en mode paquet ». Comme ce nom l'indique, il peut etre 
utilise pour tous les reseaux a commutation de paquets, en particulier IP. 

Ce protocole est specifie pour le traitement de la signalisation des donnees multimedias 
avec de fortes contraintes temporelles, comme la voix ou la video, mais aussi la realite 
virtuelle ou les jeux en reseau. 

Ce chapitre se propose de faire un tour d'horizon complet du protocole H.323. Repute 
complexe, ce protocole demeure cependant l'un des plus exploite. 



Protocoles et normalisation 

1996 a ete une annee charniere et un tournant particulierement important pour l'essor de 
la ToIP. Si cette derniere suscitait de l'interet auparavant, ce n'est qu'a partir de cette 
annee-la qu'elle commen^a a prendre son envoi en revetant un caractere normalise. 

Le handicap majeur qui freinait jusqu'alors le developpement de la telephonie IP residait 
dans l'incompatibilite des protocoles utilises pour mettre en ceuvre une communication 
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audio ou video. Lorsque deux operateurs distincts utilisent des normes de communica- 
tion differentes, il est impossible pour un utilisateur exploitant le reseau d'un operateur 
de communiquer avec un utilisateur affilie a 1' autre operateur. Pour assurer la compati- 
bility des communications, il etait indispensable de se fonder sur des bases communes. 

Pendant longtemps, un tres grand nombre de constructeurs ont tente d'imposer leur 
propre protocole comme standard. Aucun de ces protocoles proprietaires, le plus souvent 
couteux et sans legitimite particuliere vis-a-vis des autres, n'a reussi a s'imposer. Chaque 
constructeur cultivait ainsi sa difference, se montrant refractaire aux autres propositions 
et cherchant sans cesse a ameliorer le sien. 

De leur cote, les entreprises se montraient sceptiques et plus que reservees a l'idee 
d'installer des reseaux de telephonie fondes sur des protocoles instables. Du reste, l'utili- 
sation d' Internet demeurait encore modeste a l'epoque, et Ton ne parlait, dans le meilleur 
des cas, que d' exploiter la telephonie IP dans un reseau local. 

En 1996, l'editeur de logiciel Netscape, qui possedait une part de marche de 80 % avec 
son navigateur Web Navigator, annon^a la sortie prochaine de son logiciel de telephonie 
CoolTalk. Netscape nourrit l'attente, mais il ne put tenir la vedette. La conception d'un 
protocole federateur devait passer par une institution, pas par une entreprise. 

Cette meme annee 1996, 1'ITU (International Telecommunications Union) proposa la 
famille de protocoles H.32x, tres fortement soutenu par Microsoft et Intel. L'ITU parvint 
rapidement a convaincre les differents equipementiers et fournisseurs de services de la 
necessite d' adopter pour norme commune ces protocoles H.32x. 

Sans etre precurseurs ni de la telephonie, ni de la video, ni meme de la conference, ces 
protocoles constituent immanquablement 1' initiative la plus aboutie et la plus marquante 
des debuts de la signalisation multimedia. La generalisation progressive et systematique 
de H.323 finit par faire ceder les plus recalcitrants des acteurs du multimedia, qui aban- 
donnerent leurs solutions proprietaires, pourtant tres evoluees. La TolP venait de trouver 
son protocole federateur et pouvait prendre son envoi. 

Depuis, le protocole H.323 a ete adopte, implements ou supporte par de tres nombreux 
industriels, a commencer par Cisco, IBM, Intel, Microsoft et Netscape. 

La normalisation UIT 

Fondee en 1865, 1'ITU, en fran^ais UIT (Union internationale des telecommunications), 
est une des organisations internationales de normalisation les plus anciennes. Initiale- 
ment, la lettre T designait le telegraphe, et ce n'est qu'en 1932 qu'elle en vint a incarner 
le telephone. 

Installee a Geneve, l'UIT depend de l'ONU depuis 1947. Son role est de proposer des 
modeles de communication afin de favoriser les telecommunications et les services asso- 
cies, tout en reglementant au niveau mondial les usages des protocoles. C'est notamment 
a cet organisme que Ton doit la norme HD (haute definition), utilisee pour la diffusion 
cinematographique. 
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L' organisation comporte les trois comites suivants, dont les noms ont ete modifies en 
1993 a fins d' unification : 

• UIT-T, pole de standardisation des telecommunications. Ce comite normalise tout ce 
qui a trait aux transmissions, au transport et aux telecommunications. II reprend 
l'activite de l'ancien CCITT (Comite consultatif international des telegraphes et des 
telephones). 

• UIT-R, pole des radiocommunications. Ce comite normalise tout ce qui a trait aux 
signaux video et televisuels, avec la radio analogique et numerique. II reprend 
l'activite de l'ancien CCIR (Comite consultatif international des radiocommuni- 
cations). 

• UIT-D, pole de developpement des telecommunications. Ce comite est charge de 
promouvoir 1' assistance technique vers les pays en voie de developpement. II reprend 
l'activite de l'ancien BDT (Bureau de developpement des telecommunications). 

L' UIT-T a notamment deflni des standards classes et references selon une codification 
particuliere. La lettre indique la serie (de la premiere a la derniere lettre de 1' alphabet) et 
est suivie d'un chiffre identiflant chacune des recommandations de la serie. 

On retiendra notamment les series de recommandations suivantes : 

• serie E pour les recommandations liees aux generalites des reseaux, des services et des 
operations, par exemple E.164 pour le plan de numerotation de la telephonie publique 
internationale ; 

• serie G pour les recommandations liees aux systemes et supports de transmission 
multimedia, par exemple G.711 pour le codage audio avec compression ; 

• serie H pour les recommandations liees aux systemes audiovisuels et multimedias, par 
exemple H.323 pour les systemes multimedias fonctionnant en mode paquet ; 

• serie Q pour les recommandations liees aux commutations et aux signaux, par exemple 
Q.931 pour les reseaux RNIS ; 

• serie V pour les recommandations liees aux communications sur un reseau tele- 
phonique commute, par exemple V.90 pour les communications avec des modems a 
56 Kbit/s en lien descendant et 33,6 Kbit/s en lien montant ; 

• serie X pour les recommandations liees aux reseaux de donnees et aux communica- 
tions entre systemes ouverts, par exemple X.25 pour les communications en mode 
point- a-point par commutation de paquets. 

Normes dinteroperabilite 

Pour garantir le respect de la norme et verifier l'interoperabilite des plates-formes 
developpees par les industriels, plusieurs organismes ont ete mis en place. lis jouent un 
role d' intermediate entre les specifications abondantes des industriels et celles des 
concepteurs de la norme. 
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Les deux organismes de ce type parmi les plus importants sont les suivants : 

• TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks). 
Fonde par l'ETSI, ce forum permet aux acteurs de verifier la conformite et l'interope- 
rabilite de leurs specifications avec la norme H.323 a partir d'une plate-forme de test, 
appelee TIPHON-Net mise a leur disposition. 

• iNOW! Consortium (Interoperability Now!). A destination des industriels, ce consor- 
tium definit les specifications necessaires a l'interoperabilite des entites et traite de 
differents aspects, tels que la securite ou la facturation. Cree a l'initiative de VocalTec 
et Lucent en 1998, il a ensuite ete rejoint par d'autres acteurs de renom, notamment 
Alcatel, Cisco, Siemens et Ericsson. Un label iNow! est attribue aux materiels compa- 
tibles avec 1' ensemble de leurs specifications. 

Tous deux continuent aujourd'hui d'ceuvrer a ces fins. 

Les six versions de H.323 

Les premiers travaux sur H.323 ont debute en mai 1995. Depuis lors, six versions standar- 
dises se sont succede, apportant leurs lots de nouveautes et d' ameliorations. 

Le protocole H.323 impose une compatibility ascendante, ce qui veut dire que les fonc- 
tionnalites et methodes presentes dans les premieres versions du protocole restent 
supportees dans toutes celles qui suivent. Cette section presente les evolutions du proto- 
cole au cours du temps. 

H.323 version 1 (mai 1996) 

Initialement prevue dans le cadre tres restreint des reseaux locaux (LAN) n' apportant 
aucune garantie de qualite de service, la version 1 de la recommandation H.323 de l'UIT-T 
prit le nom de « Systemes et equipements visiophoniques pour reseaux locaux offrant 
une qualite de service non garantie ». 

II faudra attendre les versions suivantes pour qu'elle soit renommee « Systeme de 
communication multimedia fonctionnant en mode paquet ». Tout porte a croire que ses 
concepteurs n'avaient pas imagine rencontrer un tel succes aupres des industriels, et que 
le protocole a ensuite evolue pour adresser des reseaux plus etendus, de type Internet. 

Cette version balbutiante presentait de severes limitations, notamment des performances, 
illustrees, par exemple, par la lenteur de la mise en place d'une communication ou la 
securite, totalement absente. Surtout, la specification etait imprecise quant a la maniere 
d'implementer le protocole, ce qui entraina d' importants problemes d'interoperabilite 
entre les differents constructeurs. 

H.323 version 2 (Janvier 1998) 

Remarquable a bien des egards, la version 2 ameliora considerablement un protocole 
encore instable et perfectible, en particulier les delais d'etablissement d'une communi- 
cation grace a la procedure de FastConnect, qui permettait de paralleliser les annonces. 



La signalisation H.323 



Chapitre 3 

Une autre nouveaute fut incarnee par la procedure H.245 tunneling, qui permettait 
d'encapsuler des messages H.245 dans des messages H.225.0 (Q.931). De nouveaux 
services etaient supportes par le protocole, dont les classiques services de renvoi et de 
transfert d'appel, et des mecanismes de securite etaient rassembles dans la specification 
H.235. Cette derniere couvrait la plupart des mecanismes de securite, incluant l'authenti- 
flcation et le cryptage des flux de donnees. 

Des parametres de gestion de la qualite de service etaient ajoutes dans les messages de 
signalisation, permettant de s'integrer dans une architecture de type DiffServ ou RSVP, 
par exemple. Neanmoins, il convient de noter que la gestion elle-meme de la qualite de 
service ne faisait pas partie du protocole, H.323 n'offrant aucune garantie de reservation 
de ressources. Seuls des parametres de qualite de service pouvaient etre ajoutes dans la 
structure des paquets et pouvaient etre utilises par les terminaux. Au niveau du reseau 
cceur, ces parametres devaient etre exploites et traites par des mecanismes externes au 
protocole. 

Plus generalement, la maniere d'ajouter des services supplementaires etait decrite dans le 
document H.450.1, qui defmissait une plate-forme generique. 

Les documents suivants, numerates H.450.X (avec x > 1) decrivent de tels services : 

• H.450.2 detaille le service de transfert d'appel, qui transforme une communication 
entre deux postes A et B en une communication entre A et un autre poste, C. Elle est 
classiquement utilisee dans les entreprises pour mettre 1' appelant en relation avec la 
personne souhaitee. 

• H.450.3 detaille le service de redirection d'appel, qui remplace un poste appele par un 
autre, avec ou sans condition. Par exemple, au bout de sept sonneries sans reponse sur 
le poste d' Alice, tous les appels sont rediriges vers le poste de Bertrand ou bien tous les 
appels sans condition sur le poste d' Alice sont rediriges vers le poste de Bertrand. 

Grace au support du DTMF (Dual-Tone Multi-Frequency), le protocole H.323 version 2 
permettait la creation de nouveaux services vocaux. Au contraire de la telephonie par 
impulsion, les codes DTMF correspondent a des frequences. En assignant a chaque 
touche du terminal un code DTMF unique, il devenait possible a un serveur d' interpreter 
les saisies de l'utilisateur appelant et de lui fournir un service adequat en retour. Aupara- 
vant, les messages de signalisation ne transmettaient qu'une partie de ces informations 
DTMF, ce qui ne permettait pas d' interpreter pleinement ces signaux. 

Enfin, la recommandation H.323 permettait d'utiliser des alias a la place des adresses IP 
afin d' identifier les utilisateurs. Ces alias respectent le format des URL traditionnellement 
utilisees pour designer une ressource unique sur Internet. 

H.323 version 3 (septembre 1999) 

Globalement, la version 3 de H.323 apporte moins de nouveautes fondamentales que la 
precedente. Si la version 2 corrigeait en profondeur plusieurs imperfections de la norme 
initiale, la 3 contribuait a 1' amelioration du protocole, sans le bouleverser en profondeur. 
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Retenons notamment les trois ameliorations suivantes de cette version : 

• Gestion de nouveaux services completant la gamme existante, tels que les suivants : 

- CLIP (Connected Line Identification Presentation), ou presentation de l'identifl- 
cation de l'appel, aussi connu par son appellation commerciale d'affichage du 
numero, qui permet a l'appele de connaitre le numero d'appel de 1' appelant. 

- CLIR (Connected Line Identification Restriction), ou restriction de 1' identification 
de l'appel^ plus connu sous son appellation commerciale de masquage du numero, 
qui permet a l'appelant de limiter les possibilites d' identification de son numero. 

• Ajout de services destines a completer la serie H.450.X, tels que la mise en attente ou 
la notification d'appel ou de message en attente. 

• Integration avec la signalisation SS7, utilisee classiquement dans les reseaux tele- 
phoniques commutes. 

L' annexe E de la norme prevoyait 1' utilisation du protocole de transport UDP au lieu de 
TCP, les deux protocoles pouvant etre utilises au choix. 

H.323 version 4 (novembre 2000) 

La version 4 axait ses developpements sur la robustesse, a la fois en termes de passage a 
l'echelle (scalabilite), de flexibilite et de fiabilite. Le protocole conflrmait ainsi sa supre- 
matie par une technologie solide et veritablement en phase avec les besoins et les usages 
de tous types, y compris professionnels. La recommandation proposait pour cela des 
changements radicaux par rapport aux versions precedentes. 

Afln d'obtenir un cadre de developpement stable a la norme, cette version 4 proposait de 
formaliser les ameliorations sous forme d' extensions au protocole, mais sans modifier 
ses fondations. Autrement dit, les ameliorations ne remettaient plus en cause le principe 
de fonctionnement du protocole mais se presentaient sous la forme de modules generiques, 
appelees GEF (Generic Extensibility Framework). 

Le protocole H.323 devenait de la sorte stable, tout en autorisant des enrichissements 
progressifs. II offrait en outre un bon niveau de souplesse puisque les equipementiers 
etaient libres d'implementer certaines extensions des GEF et pas d'autres, tout en restant 
compatibles avec le socle du standard. De fait, le protocole atteignait une certaine matu- 
rity, et ses acteurs n' etaient plus obliges de suivre en permanence les evolutions et de 
mettre a jour la norme pour garantir la compatibilite. 

La notion de gatekeeper alternative, permettant le basculement des appels en cas de 
panne d'un gatekeeper, ou « garde-barriere », etait explicitee dans le document. A cette 
fin, 1' annexe R proposait des mecanismes permettant de modifier dynamiquement le 
routage des appels en cas de panne. Nous reviendrons plus loin dans ce chapitre sur les 
fonctionnalites evoluees de ce mecanisme. 

Dans cette version, le protocole H.323 se rapprochait du protocole MGCP (Media 
Gateway Control Protocol), dont les travaux etaient menes en parallele. II offrait en effet 
une nouvelle conception architecturale, qui decomposait l'equipement de passerelle 
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originate, juge trop lourd, en deux sous-parties. Cette nouvelle repartition reprenait le 
modele propose conjointement par le groupe de travail numero 16 de l'UIT-T et le groupe 
de travail MeGaCo de 1'IETF. L'UIT en proposera une nouvelle recommandation, nume- 
rotee H.248, que nous detaillons ulterieurement dans ce chapitre. 

Le protocole RTP (Real-time Transport Protocol) permet de separer les flux audio et 
video, ce qui offre aux recepteurs une plus grande flexibilite en leur permettant de choisir 
indifferemment de recevoir Tun ou 1' autre, avec un systeme de priorite. L' inconvenient 
de ce systeme est que le recepteur doit synchroniser les deux flux pour transmettre de 
fa^on parfaitement homogene la diffusion du son avec la video en simultane. Cela 
suppose des capacites complementaires, a la fois de l'emetteur, qui separe la voix de la 
video, et du recepteur, qui assure la synchronisation des deux flux. 

Avec la version 4 de H.323, le protocole proposait une solution de rechange facultative 
permettant de multiplexer la voix et la video dans un meme flux, de maniere que l'emet- 
teur n'ait plus a se soucier de la synchronisation de la video par rapport a la voix et qu'il 
puisse jouer les donnees sans que des decalages du son et de l'image soient perceptibles. 

En plus de proposer la gestion de nouveaux services, la version 4 permettait la mobilite 
de l'utilisateur et l'integration avec les reseaux GSM et UTMS. En outre, le concept 
« d'enregistrements additionnels » donnait aux utilisateurs la possibilite de s'enregistrer 
plusieurs fois aupres des gatekeepers avec plusieurs pseudonymes differents. Les paquets 
UDP etant trop courts pour permettre de specifier dans une meme requete tous les pseu- 
donymes a enregistrer, ce mecanisme d'enregistrements additionnels permettait de gene- 
rer a la suite plusieurs courtes requetes venant completer les precedents enregistrements. 

L'adressage H.323 etait fixe, et une URL H.323 pouvait desormais prendre la forme 
h323:utilisateur@ domaine, ou le prefixe h323 specifiait qu'il s'agissait d'une adresse a 
interpreter par le protocole H.323, la partie utilisateur etait un identifiant de l'utilisateur 
(ou eventuellement d'un service) et la partie domaine designait l'entite capable de 
traduire cette URL, classiquement le gatekeeper susceptible de prendre en charge la reso- 
lution de cette adresse. La fa^on de resoudre effectivement cette adresse ne sera donnee 
que dans la version suivante. 

H.323 version 5 (juillet 2003) 

Cette version est mineure par rapport aux precedentes. On peut la considerer comme une 
version de maintenance, qui repondait a un certain nombre de demandes et besoins. 

Reprenant la philosophic de stabilite initiee par la version 4, avec le cadre generique des 
GEF, la version 5 proposait des ameliorations, avec la serie de recommandations 
H.460.X, dont le tout premier document, H.460.1, expliquait ce nouveau dispositif. La 
recommandation H.460.9 permettait quant a elle aux terminaux de fournir les statistiques 
RTCP. 

L' annexe O expliquait comment utiliser les serveurs de domaines DNS (Domaine 
Name Server) pour effectuer les resolutions de noms des adresses (URL) utilisees dans 
les identifications des abonnes H.323. L' interrogation des serveurs DNS pouvait 
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s'effectuer selon differents procedes, tel ENUM (tElephone NUmber Mapping), qui 
associe un nom identifiant un utilisateur (par exemple l'utilisateur dont 1'identifiant est 
albert @ exemple.com) avec un numero de telephone conventionnel (au format a dix 
chiffres, comme 0102030405), ou A Record (Address Record), qui associe un nom 
d' utilisateur avec une adresse IP (192.168.1.15 pour une adresse en reseau local, par 
exemple). 

La version 5 gerait le protocole SCTP (Stream Control Transmission Protocol) comme 
solution de rechange aux protocoles de transport TCP et UDP. 

H.323 version 6 (juin 2006) 

Au centre de cette derniere mouture, on retrouve une philosophic modulaire, avec de 
multiples perfectionnements et des procedures simplifiees et epurees, destinees a rendre 
H.323 encore plus accessible. Quelques ameliorations sont aussi proposees, comme des 
supports plus larges, par exemple, de codecs (GSM, iLBC et H.264 sont pris en charge) 
ou de specifications de QoS (H.361 notamment). 

Le concept de gatekeeper affectee, imposant un gatekeeper fixe a un terminal, complete 
celui de gatekeeper alternatif off ert depuis la version 4. Nous reviendrons sur ce meca- 
nisme en fin de chapitre. 

En termes de securite, les mecanismes sont completement refondus. Le document de 
reference H.235 est restructure et decompose en plusieurs recommandations, numerotees 
deH.235.0aH.235.9. 

Les recommandations H.460.17, H.460.18 et H.460.18 repondent au probleme de la 
traversee des reseaux avec translation d' adresse IP, ou NAT (Network Address Transla- 
tion) et des filtres pare-feu (firewalls), qui penalisait le protocole H.323. Pendant long- 
temps, les communications H.323 ne pouvaient en effet etre mises en place dans les 
entreprises utilisant un plan d'adressage prive et des solutions de pare-feu, car le proto- 
cole H.323 utilise des ports dynamiques qui ne sont generalement pas supportes par les 
pare-feu ordinaires. 

La translation des adressages prives et logiciels des pare-feu est une solution deployee 
aujourd'hui presque systematiquement dans les entreprises, ainsi que bien souvent 
chez les particuliers. Si certains pare-feu perfectionnes et onereux proposent des 
methodes proprietaries pour permettre aux flux H.323 d'etre filtres correctement, la 
solution generale n'est veritablement donnee que dans ces nouvelles recomman- 
dations H.460. 

Ces dernieres specifient les procedures a implementer dans les gatekeepers et les termi- 
naux pour passer les translations d'adresses et traverser les pare-feu. Le principe de ces 
procedures est de conserver une connexion persistante TCP entre les terminaux et le gate- 
keeper pour assurer les communications. 

Une nouvelle entite est introduite pour permettre aux terminaux n'implementant 
pas encore les procedures de la version 6 de H.323 de traverser quand meme les 
reseaux nattes et filtres. II s'agit en ce cas d'un proxy particulier auquel s'adressent 
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les terminaux et qui agit comme un intermediaire pour relayer les messages de signa- 
lisation vers leur destinataire. En quelque sorte, si les terminaux n'arrivent pas a join- 
dre leurs correspondants parce que leurs flux sont difflcilement interpreters, le proxy 
interprete et reformate les flux avant de les envoyer vers leur destinataire. Ces derniers 
utilisent eux aussi le proxy afln que leurs flux soient conformes a ce qu'attendent les 
emetteurs. 



Architecture et fonctionnalites du protocole H.323 

Le protocole H.323 s'articule autour d'une architecture particuliere decrite dans ce qui 
suit. Cette architecture concentre les fonctionnalites autour d'entites, ce qui explique 
pourquoi le protocole H.323 est considere comme fortement centralise. 

Nous allons deflnir et detailler chacune des entites introduites par le protocole H.323. 

Les quatre entites d'une architecture H.323 

Le protocole H.323 axe tres fortement ses communications sur une typologie d'equipements. 

La terminologie anglaise etant couramment employee dans les documentations franchises, 
il convient de la connaitre. Dans ce qui suit, les premiers termes donnes peuvent etre 
consideres comme les plus courants. 

Une architecture H.323 est generalement composee des quatre categories d'entites suivantes : 

• Terminaux (au minimum deux). Ce sont les equipements de traitement destines aux 
utilisateurs, leur permettant d'emettre et de recevoir des appels. Deux terminaux 
doivent au minimum etre presents pour qu'une communication ait lieu. 

• Gatekeeper, ou garde-barriere. C'est l'equipement permettant la localisation des utili- 
sateurs. Ces derniers peuvent s'identifier entre eux par des noms, auxquels il faut attri- 
buer l'adresse IP correspondante dans le reseau ou, si l'appele n'est pas situe dans un 
reseau IP, la localisation de l'entite intermediaire a joindre pour l'appel. Outre cette 
fonction primordiale, un gatekeeper remplit tout un ensemble de fonctions comple- 
mentaires de gestion et de controle des communications, certaines etant indispensables 
et d'autres facultatives. 

• Passerelle, ou gateway. C'est l'equipement permettant a des utilisateurs du reseau IP 
de joindre les utilisateurs qui sont actifs sur d'autres types de reseaux telephoniques, 
RTC, RNIS ou ATM. On peut avoir autant de passerelles differentes que necessaire, 
suivant la nature des reseaux non-IP a interconnecter. 

• MCU (Multipoint Control Unit), ou unite de controle multipoint, parfois appelee pont 
multipoint. C'est l'equipement permettant la gestion des conferences, c'est-a-dire les 
communications multimedias mettant en jeu plus de deux interlocuteurs. Ces derniers 
doivent prealablement se connecter a la MCU, sur laquelle s'etablissent les demandes 
et negociations des parametres a utiliser lors de la conference. 
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Ces quatre entites sont illustrees a la figure 3.3. 



Figure 3.3 

Architecture de H.323 




Avant de detailler chacune de ces entites, les deux definitions suivantes doivent etre connues : 

• Points de terminaison. Terminaux, gateway et MCU sont des entites auxquelles les 
emetteurs peuvent s'adresser directement pour communiquer. Contrairement au gate- 
keeper, qui joue un role intermediaire de controle et de gestion, ces entites sont des 
points de terminaison des appels (aussi appeles endpoints). 

• Zone et systeme H.323. La nomenclature H.323 definit deux notions qu'il convient de 
bien connaitre et differencier : 

- Un systeme H.323 est defini comme un ensemble de deux terminaux au minimum, 
d'autres elements pouvant etre ajoutes. 

- Une zone H.323 est un ensemble de deux terminaux avec un gatekeeper au minimum, 
d'autres elements pouvant etre ajoutes. 

Autrement dit, une zone H.323 est un systeme H.323 associe a un gatekeeper et eventuel- 
lement, mais pas necessairement, a des entites additionnelles, comme une MCU ou une 
passerelle. Chaque entite peut etre presente en grand nombre. 

La figure 3.4 illustre ces notions de maniere hierarchique. Systeme et zone correspon- 
dent a des considerations logiques. Cela signifie que plusieurs reseaux locaux peuvent 
etre regroupes dans une meme zone H.323 et dependre d'un meme gatekeeper. 
A l'inverse, il est possible d'avoir plusieurs zones H.323 et de les faire communiquer 
entre elles. 
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Figure 3.4 

Sy steme et zones H.323 
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ZONE H.323 : composants optionnels 



Le terminal H.323, equipement des interlocuteurs 

Equipement de base des interlocuteurs, le terminal peut prendre la forme d'un telephone IP, 
en apparence semblable a n'importe quel autre appareil telephonique utilise dans la tele- 
phone RTC, ou d'un logiciel telephonique installe sur un ordinateur ou un assistant person- 
nel de type PDA equipe d'un micro et d'une sortie audio. On parle en ce cas de softphone. 

Prerequis fonctionnels des terminaux H.323 

Pour qu'un terminal soit de type H.323, il doit respecter les prerequis fonctionnels suivants : 

• Support des protocoles H.225.0 et H.245 (obligatoire). Ces protocoles, dont le premier 
utilise des protocoles herites du RNIS, avec Q.931 et RAS, ont a leur charge d'effectuer la 
partie signalisation proprement dite dans un systeme H.323. C'est pourquoi leur gestion 
est requise par les terminaux. Ces protocoles sont detailles dans la suite du chapitre. 

• Support des protocoles RTP/RTCP (obligatoire). Une fois la liaison etablie entre les 
interlocuteurs, la session multimedia peut commencer. Le transport des donnees 
recourt au protocole RTP, auquel est associe le protocole RTCP afin que 1' application 
telephonique H.323 utilisee dans le terminal puisse reguler son debit selon l'etat du 
reseau. Ces deux protocoles sont done aussi necessaires au terminal H.323. 

• Support du codec G.711 (obligatoire). Un terminal H.323 doit etre capable de gerer 
1' audio et, suivant les usages, les textes, images et eventuellement videos. Pour cela, il 
doit necessairement supporter au moins le codec audio G.711, selon l'une de ces deux 
variantes : PCM (Pulse Code Modulation), la loi mu utilisee en Amerique du Nord et 
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en Asie, et MIC (modulation, impulsion et codage), la loi A utilisee en Europe et dans 
le reste du monde. Le support des autres codecs audio et de 1' ensemble des codecs 
video est laisse libre et optionnel dans la specification du protocole H.323. 

• Support de liaisons asymetriques (optionnel). Les terminaux peuvent etre disposes 
de fa^on a etablir des communications asymetriques, pour lesquelles la reception de 
donnees se fait avec un codec different de celui utilise pour 1' envoi. Par exemple, un 
meme terminal peut utiliser le codec G.222 en reception et le codec G.7 1 1 en emission. 
Cela permet d'affmer les debits selon les capacites des terminaux. 

A titre d' exemple, considerons deux terminaux A et B, dont le premier a un debit 
descendant (reception ou download) fort mais un debit montant (envoi ou upload) 
faible, et le second un debit montant et descendant fort. Le terminal A peut utiliser un 
codec de tres bonne qualite pour la reception et un codec de moins bonne qualite pour 
l'envoi. Parallelement, le terminal B doit s'adapter aux capacites de son correspondant 
en utilisant le meme codec de bonne qualite pour l'envoi et le meme codec de moins 
bonne qualite pour la reception. Les liaisons sont de la sorte asymetriques. 

• Support du multicast (optionnel). Si le terminal doit servir a la mise en place de confe- 
rences, le multicast doit etre gere par le terminal. II permet de dialoguer sans 1' interven- 
tion d'une entite specialisee, telle qu'une MCU, en diffusant ses messages dans le reseau, 
sous reserve que ce dernier dispose de routeurs qui autorisent la diffusion en multicast. 

Comme l'illustre la figure 3.5, des terminaux peuvent parfaitement communiquer entre 
eux en utilisant le protocole H.323 et sans l'intervention d'autres elements architectu- 
raux. lis forment ainsi un systeme H.323 autonome, mais leurs communications ne 
peuvent proflter de la gamme de services fournie par les autres entites. En particulier, les 
utilisateurs doivent imperativement connaitre l'adresse IP de leur correspondant pour 
pouvoir les joindre. En outre, ils restent cloisonnes dans un reseau purement IP, ce qui 
represente une contrainte tres limitative pour H.323, qui vise a offrir une large communi- 
cation entre differents types de reseaux. 




Terminal H.323 ^1 V Terminal H.323 



Figure 3.5 

Communication entre deux terminaux H.323 
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Le gatekeeper, point de controle et de gestion 



Facultatif de maniere generate, le gatekeeper est requis pour toutes les operations de 
controle et de gestion des communications. II offre de la valeur ajoutee aux communica- 
tions en proposant plusieurs fonctions, dont la premiere consiste a assurer la localisation 
des abonnes. Progressivement, le gatekeeper est devenu un element central dans lequel se 
concentrent toutes les fonctionnalites additionnelles, offrant une gamme de services 
complementaires. L' architecture de H.323 est done fortement centralisee autour de lui. 

Si un gatekeeper est present dans une zone H.323, tous les terminaux doivent necessaire- 
ment s'y enregistrer et y sollicker l'autorisation d'effectuer des appels, en emission 
comme en reception. 

Localisation des abonnes 

Pour permettre la localisation des utilisateurs dans un reseau IP utilisant H.323, le gate- 
keeper effectue la conversion d'un alias en une adresse IP. 

Un alias est un identiflant associe a un utilisateur. Chaque utilisateur est localise dans le 
reseau IP par une adresse IP, mais cette adresse peut etre attribute dynamiquement. Pour 
etre joignables, les utilisateurs ne sont pas identifies par cette adresse IP, qui est impropre 
a les qualifier pleinement et univoquement, mais par un alias qui les represente et que les 
utilisateurs peuvent s'echanger pour se contacter. 

Le gatekeeper se charge d'effectuer la correspondance entre les alias et les adresses IP. Les 
utilisateurs qui ne sont pas situes dans un reseau IP doivent aussi pouvoir etre joignables 
par les utilisateurs du reseau IP. C'est a nouveau le gatekeeper qui permet de les localiser. 

Un alias peut etre deflni de plusieurs fagons : 

• une adresse de type e-mail, eventuellement prefixee de l'indication h323: speciflant 
qu'il s'agit d'un alias H.323 ; 

• une adresse de type numero de telephone (recommandation E.164 de l'UIT-T) ; 

• une chaine de caracteres Unicode quelconque ; 

• une adresse de type URL ; 

• une adresse IP, eventuellement sufflxee du numero de port a utiliser. 

Les adresses suivantes sont done des alias H.323 valides : albert@domaineH323.com, 
albert323, 132.227.55.155:1720, 0323323323, etc. 

La translation d'un alias vers une adresse IP est illustree a la figure 3.6. Lors de sa 
connexion au reseau IP, Bertrand indique au gatekeeper sa localisation dans le reseau 
(etape 1), comme tout utilisateur qui se connecte. Le gatekeeper a sauvegarde cette asso- 
ciation de l'alias avec l'adresse IP correspondante dans sa base de donnees. Lorsqu' Alice 
souhaite joindre Bertrand, elle ignore sa localisation mais dispose de son alias. En solli- 
citant le gatekeeper (etape 2), Alice peut done determiner la localisation de Bertrand 
(etape 3) puis initier un appel vers ce dernier (etape 4). Nous verrons plus loin a quelles 
requetes et reponses correspond chacune de ces etapes. 
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Figure 3.6 
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Autres fonctionnalites du gatekeeper 

Initialement charge d' assurer seulement cette traduction d'adresses, le gatekeeper est 
progressivement devenu un equipement de point de controle dans lequel se concentre 
1' ensemble des fonctionnalites complementaires du reseau. 

Parmi elles, les fonctionnalites suivantes sont specifiees dans la norme comme indispen- 
sables et implementees systematiquement dans tous les gatekeepers : 

• Controle d' admission. Si la bande passante ne permet pas d'etablir un nouvel appel 
dans une zone H.323, la passerelle est habilitee a interdire de nouveaux appels et a 
etablir une liste de priorites d' appels licites. 

• AAA (Authentication, Authorization, Accounting), ou authentification, autorisation et 
comptabilisation. L' authentification permet de connaitre l'identite de la personne 
connectee, tandis que 1' autorisation indique quels sont les droits (et eventuellement les 
conditions) attribues a la personne qui s'est authentifiee. 

• Gestion des flux. Le gatekeeper peut implementer un gestionnaire de bande passante pour 
decider de 1' allocation de bande affectee aux terminaux. II est en outre possible de limiter 
le nombre d'intervenants dans une conference et de rejeter certaines demandes de flux 
(par exemple en n'autorisant que la voix a un utilisateur qui reclame 1' audio et la video). 

Optionnellement, il est possible d' implementer au sein de ce serveur des fonctionnalites 
de gestion et de surveillance de la zone H.323 de fa^on a assurer divers services, notamment 
les suivants : 

• gestion des couts, par le biais d'un systeme de facturation s'interfa^ant avec les appels 
et calculant la duree de chaque communication ; 

• mise en place d'annuaire, particulierement utile en entreprise, mais tout aussi dispo- 
nible dans un cadre plus vaste ; 
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• gestion des appels avec differents services proposes, notamment le transfert d'appel, la 
raise en attente, la restriction d' appels en provenance de terminaux specifiques ou bien 
a des horaires determines, entre autres possibilites ; 

• historique des appels effectues, sauvegardes dans des journaux et ulterieurement 
exploitables ; 

• generation de statistiques d' utilisation. 

Ces possibilites peuvent etre etendues, et il ne s'agit ici que d'exemples courants. 

Signalisation routee et directe 

Pour mettre en relation deux utilisateurs, il est possible d'utiliser deux moyens differents 
pour faire transiter la signalisation dans le reseau : 

• un mode indirect, ou route, la signalisation entre les correspondants passant par le gate- 
keeper ; 

• un mode direct, la signalisation entre les correspondants ne faisant intervenir que ces 
correspondants, sans entite intermediaire. 

Dans le mode indirect, toute la signalisation passe systematiquement par le gatekeeper. 
Ce dernier garde done la supervision totale de la communication et peut intervenir ensuite 
lors des negotiations entre les utilisateurs, en interdisant certains flux video, par exem- 
ple, ou en sauvegardant les parametres negocies lors de l'appel, ce qui peut etre utilise a 
des fins de facturation notamment. 



Figure 3.7 
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Comme l'illustre la figure 3.7, l'inconvenient immediat de cette methode est que le gate- 
keeper, deja fortement sollicite dans une zone H.323, Test davantage encore puisqu'il fait 
transiter l'ensemble des messages de signalisation. 
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Seule la partie signalisation de l'appel est concernee par cette redirection vers le gatekee- 
per, la transmission des flux multimedias eux-memes ne faisant pas intervenir le gatekeeper 
mais seulement les utilisateurs finals. 

Dans le mode direct, les interlocuteurs s'echangent la signalisation entre eux, comme 
l'illustre la figure 3.8. Le gatekeeper joue cependant toujours son role, et les intervenants 
l'utilisent pour effectuer prealablement a l'appel la traduction d'adresse permettant de 
localiser le terminal appele puis pour s'y authentifier et etre soumis au controle d' admis- 
sion ainsi qu'a toutes les fonctionnalites dont dispose le gatekeeper. Ce n'est qu'ensuite 
que les informations de signalisation sont envoyees uniquement entre les correspondants, 
exactement comme pour un appel dans un systeme H.323 ne faisant pas intervenir de 
gatekeeper. 



Figure 3.8 
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La passerelle, pourjoindre les reseaux ne fonctionnant pas en mode 
paquet 

Le protocole H.323 s'appuie necessairement sur un reseau a commutation de paquets. Le 
reseau telephonique classique, dit RTC (reseau telephonique commute), repose quant a 
lui sur une technologie a commutation de circuits, non compatible avec la commutation 
de paquets. II est done important que le protocole H.323 fournisse les moyens de 
communiquer avec les utilisateurs RTC. 

A l'origine meme de H.323, la recommandation H.320 visait a specifier les caracteristi- 
ques des systemes et equipements de videoconference dans un reseau RNIS. Cette 
recommandation a ensuite ete declinee pour les autres types de reseaux (serie de recom- 
mandations H.32x), donnant naissance a H.323. II est done naturel que la jonction entre 
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ces reseaux soit prevue. Cette fonctionnalite est fournie par un equipement dedie, la 
passerelle. 

La passerelle assure 1' interconnexion d'un reseau a commutation de paquets (typique- 
ment les reseaux IP) avec les reseaux qui ne sont pas a commutation de paquets, incluant 
notamment les reseaux RTC, RNIS et ATM, afin de permettre a des utilisateurs du reseau 
IP de joindre des utilisateurs d'un autre type de reseau. 

La figure 3.9 illustre le role d'une passerelle pour joindre un reseau tel que RTC. 



Gatekeeper 



Terminal H,323 




Terminal telephonique 



Figure 3.9 

Utilisation d'une passerelle pour joindre un reseau non IP 
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Le concept de passerelle est tres large et ne concerne pas seulement le protocole H.323. 
Une passerelle est en effet requise chaque fois que Ton souhaite joindre un reseau non-IP. 
Elle est indispensable, par exemple, pour joindre un telephone conventionnel a partir 
d'un ordinateur relie a Internet. C'est pourquoi les fournisseurs d'acces ont systemati- 
quement recours a des passerelles, qui ne sont pas forcement correlees avec le protocole 
H.323, pour offrir leur service de telephonie a leurs abonnes. 

Les passerelles sont des equipements optionnels, dont la presence impose celle d'un 
gatekeeper, puisque la localisation de l'appele ne peut etre fournie que par ce dernier. 
Les utilisateurs d'un reseau non-IP ne disposant pas d'adresse IP, si un utilisateur du 
reseau IP dispose d'un numero de telephone pour joindre un contact, il doit demander 
au gatekeeper qui regit la zone, a quelle passerelle il doit s'adresser pour trouver son 
interlocuteur. 

Comme illustre a la figure 3.10, les normes suivantes permettent de specifier 1' inter- 
connexion entre les reseaux : 

• H.320 pour les reseaux RNIS ; 

• H.310 et H.321 pour les reseaux ATM ; 

• H.322 pour les reseaux locaux offrant une qualite de service ; 

• H.324 pour les reseaux a commutation de circuits (RTC). 

Sans etre exhaustive, cette liste est significative de la grande flexibilite offerte en termes 
d'adaptation et d'interfa^age aux reseaux ne fonctionnant pas en mode paquet, puisqu'on 
y retrouve les reseaux les plus repandus. 

La complexity des passerelles a incite les equipementiers a implementer des modifica- 
tions proprietaries aux procedures decrites dans les normes protocolaires afin de simpli- 
fier leur utilisation. Dans ces cas, le respect des recommandations n'etant pas rigoureux, 
l'interoperabilite entre constructeurs n'est pas necessairement assuree. 

La passerelle est tenue d' assurer les deux fonctionnalites suivantes : 

• Correspondance de signalisation. La signalisation utilisee dans un reseau IP etant 
differente de celle utilisee dans un reseau, par exemple, RTC, la passerelle se charge de 
convertir un signal de controle respectant la norme H.323 des reseaux IP en un signal 
de controle equivalent respectant la norme d'un reseau RTC. Pour joindre le reseau 
RTC, la passerelle adapte done les messages H.323 en messages SS7. 

• Adaptation des supports de communication. Cela permet d' assurer la cohesion entre 
les medias en garantissant notamment les operations de multiplexage des donnees, de 
correspondance des debits et de transcodage audio. Ainsi, 1' interlocuteur dans le 
reseau IP peut utiliser un certain codec, tandis que son correspondant en utilise un 
autre. Tous les flux transitent par la passerelle, qui se charge d'effectuer la correspon- 
dance de ces codecs et de transmettre a chaque intervenant le type de flux qu'il sait 
interpreter. 
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Figure 3.10 

Normes d' interconnexion de reseaux par le biais d'une passerelle 



Architecture de la passerelle 

Les fonctionnalites des passerelles en ont fait des equipements lourds, complexes, tres 
sollicites et couteux. C'est la raison pour laquelle la version 4 de la recommandation 
H.323 a epure leur role. 

Consciente de la charge importante assignee a la passerelle, l'UIT a travaille de concert 
avec 1'IETF arm de simplifier ses fonctionnalites en la decomposant en deux sous-entites 
compatibles avec le modele de la recommandation H.248 : une entite de traitement, appe- 
lee MG (Media Gateway), ou passerelle multimedia, et une entite de controle, appelee MGC 
(Media Gateway Controller), ou controleur de passerelle multimedia. 

Dans cette nouvelle architecture, l'ancienne passerelle devient une Media Gateway, qui a 
pour unique fonction d'effectuer le transcodage audio entre les differents reseaux. Toutes 
les MG sont elles-memes reliees et controlees par le MGC, lequel agit comme un contro- 
leur unique, centralisant 1' ensemble des signalisations de controle entre les differents 
reseaux. Si les MG sont les entites qui appliquent les traitements, le MGC est 1' entite de 
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gestion qui donne les ordres aux MG. Nous reviendrons sur ce modele au chapitre 5, 
dedie au protocole MGCP. 

Retenons pour l'heure que la passerelle se decompose en deux sous-parties, la passerelle 
multimedia et le controleur. Ces deux fonctionnalites logiques distinctes peuvent etre 
regroupees au sein d'une meme machine, notamment s'il n'y a qu'une seule passerelle. 

La MCU et les conferences 

La MCU (Multipoint Control Unit) est utilisee pour mettre en place des conferences 
multimedias entre plusieurs utilisateurs, au moins deux. Comme l'illustre la figure 3.11, 
tous les utilisateurs desireux de participer a une conference doivent se connecter a la 
MCU afin d'y definir et de negocier les parametres de communication a utiliser. 
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Figure 3.11 

Role de la MCU lors d'une conference 



Contrairement aux autres types d'equipement, la MCU ne s'interesse pas uniquement a 
la signalisation, mais aussi au transfert des donnees multimedias. Nous allons decrire les 
entites constituantes d'une MCU, avant d' examiner comment s'effectue une conference 
multimedia. 
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Le controleur et I'executant 



La MCU designe un equipement compose de deux entites, qui jouent un role comple- 
mentaire, le MC (Multipoint Controller) et le MP (Multipoint Processor). 

MC (Multipoint Controller) 

Le Multipoint Controller est charge de la negociation des parametres. En prealable a la 
conference, tous les utilisateurs negocient 1' ensemble des parametres de communication 
qu'ils desirent utiliser, selon les capacites de leur terminal et leur souhait. lis conviennent 
notamment du mode d'adressage (unicast ou multicast), du type de flux souhaite (audio, 
video ou les deux), du codec a utiliser et de la bande passante necessaire. 

C'est le MC qui centralise la demande de chacun des intervenants et leur fournit en 
reponse les parametres effectifs a utiliser, en essay ant d'optimiser les sollicitations faites 
par 1' ensemble des terminaux. 

Le MC n'intervient que pour les signaux de controle, a 1' exclusion done des donnees 
multimedias proprement dites, auxquelles il ne s'interesse pas. Contrairement au MP, le 
MC n'est pas un intermediate de la communication. II est toujours soit emetteur soit 
recepteur des messages et ne fait pas transiter les messages qu'il re^oit d'un poste vers un 
autre. 

MP (Multipoint Processor) 

Le Multipoint Processor est un centre de traitement des flux multimedias. 

Dans une conference, chaque utilisateur peut disposer de parametres specifiques. L'un 
peut reclamer un codec audio de tres bonne qualite, un autre un codec de moins bonne 
qualite, un troisieme ajouter la video en plus de 1' audio. Pour satisfaire ces demandes, 
tous les utilisateurs se connectent aupres de l'entite MP, laquelle leur delivre a chacun, 
dans la limite de ses possibilites, les flux qu'ils sollicitent. 

Concretement, chaque intervenant adresse au MP 1' ensemble de ses flux. Lorsqu'il les 
re^oit, le MP assure le multiplexage des paquets, ainsi que la synchronisation des 
donnees (regulation des diffusions et synchronisation des flux de voix avec les flux de 
video) et 1' adaptation des formats de codage et des debits. Les flux resultants sont 
envoyes aux destinataires. 

Le MP permet de centraliser et d' adapter les echanges, mais ce n'est pas un composant 
obligatoire pour les conferences. De plus, comme il est fortement sollicite par les inter- 
venants, il est possible d'associer a un meme MC plusieurs MP. 

Comme la MCU definit une fonctionnalite logique, n'importe quelle autre entite peut 
jouer son role, y compris les terminaux et le gatekeeper. Mais il est generalement 
preferable d' avoir un seul serveur dedie, disposant de la puissance de traitement suffl- 
sante pour tenir des charges importantes sans degrader les performances des communi- 
cations. 
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Les trois modes de diffusion possibles 

Pour offrir un service de conference dans un reseau telephonique, il est necessaire de 
disposer de ressources reseau tres importantes. En effet, chaque participant doit indivi- 
duellement etre mis en relation avec chacun des autres intervenants de la conference, 
avec autant de liaisons a son extremite qu'il y a d' intervenants. 

La figure 3.12 illustre l'architecture d'une telle conference avec quatre participants. 



Figure 3.12 

Architecture d'une conference a 
quatre participants en diffusion 
point-d-point 




Tous les participants de la communication etant mis en relation en point-a-point, cela 
reclame, pour chaque terminal, autant de liaisons qu'il y a d' intervenants. De plus, 
comme rien n'est centralise, il est necessaire de mettre en place des canaux dedies. 

Dans le monde IP, il est possible de reduire considerablement l'utilisation des ressources 
par trois methodes : la centralisation des flux, la diffusion multicast et une combinaison 
de ces deux techniques. 

Mode centralise (unicast) 

Une premiere methode consiste a centraliser les flux vers un serveur unique. Ainsi, 
chaque utilisateur ne communique en unicast qu'avec ce serveur, lequel est en charge de 
la diffusion des flux a tous les abonnes inscrits a la conference. 

Dans ce cadre, la MCU fonctionne comme indique precedemment : les capacites MC et 
MP sont parfaitement adaptees pour respectivement recueillir les demandes de chacun 
des participants et leur fournir les flux adequats. 

L'avantage de cette methode est que la MCU peut effectuer des traitements sur tous les 
flux qui transitent par elle. En outre, chaque intervenant ne maintient qu'un lien unique 
vers elle. Son inconvenient est la forte sensibilite aux pannes de l'architecture puisque la 
MCU est au centre des communications. En outre, l'utilisation de la bande passante reste 
importante, les paquets etant systematiquement envoyes vers la MCU avant d'aller vers 
les destinataires. Cela equivaut a deux routages de flux, alors qu'un cheminement de 
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l'emetteur vers les recepteurs n'impliquerait qu'un seul routage. C'est l'idee du mode 
decentralise. 

Mode decentralise (multicast) 

Une autre possibilite pour mettre en oeuvre des conferences consiste a decentraliser les 
communications sans faire intervenir d' intermediate de transit. Les terminaux 
communiquent en ce cas directement entre eux. 

Pour reduire l'utilisation de la bande passante, ils utilisent un adressage multicast, qui 
offre une diffusion unique des messages a 1' ensemble du reseau. Ce scenario est illustre a 
la figure 3.13, dans laquelle quatre participants communiquent entre eux. Leurs messages 
transitent par des routeurs, qui sont capables de diffuser les flux simultanement sur 
plusieurs liens en meme temps. 



Figure 3.13 

MCU en mode decentralise 
(multicast) 




La MCU n'est pas directement visible dans ce cadre, mais elle reste necessaire pour que 
tous les intervenants conviennent des parametres a mettre en place dans la communica- 
tion. La MP s'avere totalement inutile ici, et la MCU se trouve reduite a sa seule fonction- 
nalite de MC, c'est-a-dire a sa partie controle. 

Globalement, 1' adressage multicast reduit considerablement les diffusions, puisque 
chaque message n'est diffuse qu'une fois dans le reseau. L'utilisation de la bande 
passante s'en trouve done sensiblement diminuee. En outre, et contrairement a la solu- 
tion precedente, les terminaux doivent effectuer eux-memes les traitements sur les flux, 
ce qui presente l'avantage de distribuer la charge du MP entre les terminaux. L'inconve- 
nient majeur de cette methode est que les composants du reseau doivent supporter le 
multicast. Cela vaut a la fois pour les routeurs, qui entrent dans le processus de routage 
des flux, et pour les pare-feu, qui doivent etre disposes a laisser passer les flux multicast. 
Ces contraintes se revelent particulierement fortes dans la pratique. 
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Mode hybride 

Le mode de diffusion hybride utilise les deux methodes precedentes de fa^on combinee. 
L'idee est de differencier les usages, soit par utilisateur, soit par type de flux, afin de four- 
nir un service adapte. Dans le cadre d'une meme conference, le mode centralise peut 
ainsi etre dedie a 1' audio et le mode decentralise a la video. 

Le MP est de la sorte raisonnablement sollicite pour les besoins des flux audio unique- 
ment et peut assurer les traitements pour les terminaux de faibles capacites. Quant aux 
autres terminaux, ils peuvent disposer de la video en traitant ces types de flux. La distinc- 
tion peut se faire suivant les contraintes de chaque terminal, en tenant compte notamment 
de ceux qui ne peuvent faire de multicast, du fait des equipements intermediaries. 

Ce mode permet au cas par cas de combiner les avantages et les inconvenients des modes 
precedents. Dans ce cadre, la MCU peut exploiter pleinement les capacites MC (pour 
tous les flux) et MP (pour les flux centralises). 

Les messages H.323 

Bien plus qu'un protocole, H.323 renvoie a une plate-forme complete decrivant comment 
des protocoles se combinent pour assurer la signalisation. Pour etre fonctionnel, H.323 
doit imperativement utiliser d' autres protocoles, qui forment son ossature. Les plus 
importants d'entre eux sont les standards fondamentaux H.225.0, qui exploite les proto- 
coles RAS et Q.931, herites du RNIS, et H.245. 

Le protocole H.225.0 met en place un canal de signalisation d'appel et d'enregistrement 
afin d' assurer la mise en relation des interlocuteurs. Le protocole H.245 permet quant a 
lui de creer un canal de controle pour la negotiation des parametres de la communication 
(codeur utilise, controle de flux, etc.). 

Les couches protocolaires de ce modele sont illustrees a la figure 3.14. 



Figure 3.14 
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Initialement, les protocoles H.245 et Q.931 ne supportaient que le protocole de trans- 
port TCP, mais depuis la version 3 de H.323, ils supportent indifferemment TCP et 
UDR 

Les specifications de ces protocoles etant particulierement complexes, nous ne detaille- 
rons pas tous les mecanismes mis en ceuvre lors d'une communication H.323 et nous 
nous contenterons d' observer les cas de figure les plus classiques des appels. 

Dans les sections qui suivent, un endpoint est defini comme une entite source ou 
destinataire d'un message, qui peut correspondre aussi bien a un terminal qu'a une 
passerelle. 

Le protocole H. 225.0, signalisation d'appel et d'enregistrement 

Le protocole H. 225.0 est utilise pour permettre la signalisation d'appel et la signalisation 
d'enregistrement (avec le controle d' admission). Ces deux types de signalisation sont 
assures par les protocoles RAS (Registration Admission Status) et Q.931. 

La signalisation d'appel avec Q.931 

La signalisation d'appel permet l'etablissement d'un appel, la liberation de la communi- 
cation et la transmission des messages indiquant l'etat d'un appel (occupation d'un 
poste, redirection, etc.). Elle regroupe les fonctionnalites de mise en paquet, de synchro- 
nisation, de multiplexage et de confidentialite. 

C'est le protocole Q.931, egalement utilise dans le cadre des reseaux RNIS, qui specifie 
cette partie de la signalisation. Seul un sous-ensemble de ces messages Q.931 est appli- 
cable dans le protocole H.323. 

Les cinq messages fondamentaux suivants doivent obligatoirement etre supportes : 

• setup : envoye pour initier et etablir une communication avec un terminal H.323. 

• alerting : indique que le poste appele est en train de sonner et que 1' appelant se met 
en attente de sa reponse. 

• CONNECT : indique que la communication peut debuter. 

• release complete : envoye pour initier la terminaison de 1' appel. 

• status facility : envoye pour demander des services complementaires. 

Nous allons montrer comment s'effectuent l'ouverture et la fermeture d'un canal de 
signalisation d'appel, en restreignant le scenario aux seules etapes qui relevent de la 
signalisation Q.931 (sans la localisation de 1' appele notamment). 

Exemple 1 . Ouverture du canal de signalisation d'appel 

L'ouverture d'un canal de signalisation d'appel se fait generalement en trois etapes : 
1. Message setup : 1' appelant contacte son correspondant. 
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2. Message alerting : la sonnerie du terminal appele retentit, et le terminal se met en 
attente de la reponse du correspondant. 

3. Message connect : des que l'appele a decroche, ce message previent l'appelant de la 
disponibilite de son interlocuteur. 

Ce scenario est illustre a la figure 3.15. 



Figure 3.15 

Ouverture d'un canal 
de signalisation d'appel 



Terminal H.323 
Appelant 



Terminal H.323 
Appel6 




Exemple 2. Fermeture du canal de signalisation d'appel 

La fermeture d'un canal de signalisation d'appel se fait a l'initiative de 1' interlocuteur qui 
a raccroche son combine, mettant fin a la conversation. 

Un message release complete est envoye pour fermer le canal de signalisation d'appel. 
Ce scenario est illustre a la figure 3.16. 
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La signalisation d'enregistrement avec RAS 

Le protocole RAS (Registration Admission Status) intervient pour les dialogues entre les 
terminaux et le gatekeeper, done necessairement dans une zone H.323. 

Entre le terminal et le gatekeeper, on parle d' interface RAS pour indiquer que des messa- 
ges RAS sont echanges entre ces deux entites. Le protocole RAS utilise UDP comme 
protocole de transport et les ports 1719 pour la diffusion d'un message a un seul destina- 
taire (mode unicast) et 1718 pour les diffusions multiples (mode multicast). Generale- 
ment, tous les messages sont envoyes en unicast. 

Messages RAS generiques 

Les messages RAS sont relativement simples et ressemblants. Chaque action possede 
generalement les trois declinaisons de messages suivantes : 

• xRQ : indique un message RAS de requete (request). 

• xRJ : indique un message RAS de rejet de la requete (reject). 

• xCF : indique que la requete a ete correctement traitee (confirm). 

Le caractere x est ici generique et concerne n'importe quel message. Le tableau 3.1 reca- 
pitule les principales requetes du protocole RAS. Chacune d'elles dispose des declinai- 
sons de reponse xRJ et xCF. 

Tableau 3.1 - Principales requetes RAS 

Message Norn de reference Description 
RAS 



GRQ gatekeeper request En envoyant ce message, le endpoint recherche un gatekeeper suscep- 

tible de le prendre en charge. Plusieurs gatekeepers peuvent repondre. 
L'adresse du gatekeeper peut etre renseignee en statique sur le end- 
point ou etre determined par une resolution de type DNS (selon 
I'Annexe 0). 

RRQ registration request Ce message permet au endpoint de s'enregistrer aupres du gatekeeper et 

de recuperer les services auxquels il a droit (voir section suivante). Dans le 
meme temps, le gatekeeper affecte au endpoint un identifiant servant a ce 
dernier de reference pour tous les messages echanges avec le gatekeeper. 
Un parametre « time to live » envoye par le endpoint dans la requete indi- 
que la duree maximale au bout de laquelle le gatekeeper peut supprimer 
I'entree associee au endpoint s'il n'a pas detecte d'activite de ce dernier. 
A tout moment, le endpoint peut rafraichir son entree (et done son parame- 
tre « time to live ») soit par un message complet RRQ, soit par un message 
plus court appele LWRRQ. 

LWRRQ lightweight Ce message rafraichit I'enregistrement d'un endpoint. II ne peut que faire 

registration request suite a un message RRQ et ne remplace pas ce dernier pour un premier 
enregistrement de endpoint. Plus court qu'un message RRQ, il est prefe- 
rable pour rafraichir une entree. 
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Tableau 3.1 - Principales requetes RAS (suite) 



Message Nom de reference 
RAS 



ARQ 



ADMISSION REQUEST 



LRQ 

BRQ 
DRQ 



LOCATION REQUEST 



BANDWIDTH REQUEST 



DISENGAGE REQUEST 



Description 

Pour initier ou recevoir un appel, un endpoint doit etre soumis a un controle 
d'admission aupres du gatekeeper. Le endpoint specifie dans sa requete 
s'il est I'initiateur ou le recepteur de I'appel, ainsi que de quelle quantite de 
bande passante il a besoin et la valeur des deux parametres suivants : le 
Call-Id (call identifier) referengant un appel de maniere unique et le CID 
(conference identifier) referengant une conference en particulier (partage 
par tous les conferenciers et a la valeur si cet identifiant n'est pas deter- 
mine). En retour, le gatekeeper autorise ou interdit I'appel selon des autori- 
sations, droits d'acces et contraintes de qualite de service du reseau a 
respecter. Notamment, il peut decider de reduire la bande passante 
demandee. 

Ce message est envoye a un gatekeeper soit par un endpoint, soit par un 
gatekeeper pour demander la localisation d'un utilisateur, autrement dit 
pour resoudre un alias H.323 (par exemple, un numero de telephone) en 
une adresse IP. Generalement, c'est le gatekeeper qui se charge de la loca- 
lisation. 

Ce message est utilise par un endpoint pour demander au gatekeeper plus 
ou moins de bande passante qu'initialement sollicitee. 

Ce message peut etre envoye par un endpoint vers un gatekeeper pour 
indiquer que la communication a pris fin ou par le gatekeeper vers un end- 
point pour forcer ce dernier a terminer un appel. En principe, un gatekeeper 
ne doit pas envoyer de message de rejet DRJ a cette requete puisqu'il s'agit 
plutot d'une information que d'une requete (utile, par exemple, pour connai- 
tre la duree de I'appel a des fins de facturation). 



Messages RAS particuliers 

On observe des exceptions dans la declinaison de messages de types xRQ/xRJ/xCF. 

Les messages suivants sont egalement des messages RAS : 

• request in progress (RIP). Le message RIP est une reponse temporaire qui acquitte 
la reception de la requete en indiquant que son execution n'a pu etre realisee dans un 
delai normal mais qu'elle continue d'etre traitee. 

• information request (IRQ)/information response (IRR). La requete IRQ est 
envoyee par le gatekeeper vers un endpoint pour avoir des informations sur l'etat d'une 
entite, par exemple pour connaitre la disponibilite d'un terminal ou l'etat d'un appel. 
La reponse est faite par un message IRR, qui decrit les informations demandees. Si un 
gatekeeper regoit un message IRR alors qu'il n'a pas envoye de requete IRR, il repond 
generalement par un message RAS d'acquittement. 

• RESSOURCE AVAILABLE INDICATE (RAI)/RES SOURCE AVAILABLE CONFIRM (RAC). La 
requete RAI indique qu'un terminal a atteint ou est sur le point d'atteindre les capa- 
cites maximales disponibles. La confirmation par le gatekeeper de la reception du 
message RAI se fait par le message RAC. 
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• SERVICE CONTROL INDICATION (SCI)/SERVICE CONTROL RESPONSE (SCR). La requete 

SCI sollicite un service speciflque (aupres d'un terminal ou d'un gatekeeper), dont la 
reponse est envoyee par le message SCR. 

• non-standard MESSAGE. Permet d'echanger des messages personnalises (et done non 
standards) entre le gatekeeper et un terminal. 

• unknown MESSAGE RESPONSE. Utilise pour indiquer que le message de requete n' a pas 
ete reconnu (la requete est soit incorrecte, soit non prise en charge). 

L' ensemble de ces messages reste cependant assez exceptionnel. 

Exemple 1 . Enregistrement d'un terminal aupres d'un gatekeeper 

Lorsqu'un terminal se connecte dans une zone H.323, il doit s'enregistrer aupres du gate- 
keeper de la zone afln de lui indiquer sa presence dans le reseau, et done sa disponibilite 
potentielle. Cela permet de recenser les terminaux pour ensuite fournir le service de loca- 
lisation d'un utilisateur, soit a un terminal appelant, soit a un autre gatekeeper. 

Le terminal fournit dans sa requete d' enregistrement son adresse IP associee a son iden- 
tiflant H.323. De cette maniere, tout utilisateur souhaitant joindre un terminal enregistre 
aupres du gatekeeper peut sollicker ce dernier en lui mentionnant l'identiflant H.323 du 
terminal a joindre. Dans le meme temps, le terminal reclame au gatekeeper de disposer 
des services auxquels il a droit. 

Ce scenario d'utilisation classique est illustre a la figure 3.17. 



Figure 3.17 
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II se deroule de la fa^on suivante : 

1. La requete RRQ (registration request) est envoy ee par le terminal au gatekee- 
per pour mentionner a ce dernier sa disponibilite dans le reseau. Les services sont 
demandes implicitement par cette requete. L' authentiflcation peut etre effectuee 
en meme temps, de maniere a proscrire l'usurpation d'identite entre utilisateurs. 

2. En reponse, le gatekeeper retourne soit un message RCF (registration confirm) 
pour valider la demande d'enregistrement, soit un message RRJ (registration 
reject) pour la refuser. Plusieurs raisons peuvent expliquer cet echec, notam- 
ment si la requete est incorrectement formulee ou si le gatekeeper a sature sa 
base de donnees d'enregistrement ou encore si le gatekeeper est soumis a des 
restrictions sur les enregistrements et ne supporte qu'une liste d'abonnes fixes, 
par exemple. 

Exemple 2. Localisation d'un terminal 

Le principe de la localisation d'un terminal a deja ete mentionne en presentation du role 
du gatekeeper. Nous mentionnons ici les messages relatifs a ce mecanisme. 

La figure 3.18 illustre les differentes etapes de localisation d'un utilisateur. Nous suppo- 
sons que les terminaux se sont prealablement enregistres et associes chacun a un gatekeeper 
different. 



Terminal H.323 
de Alain 



Gatekeeper 




2.LRQ 



3.LCF 



5. Tentative de connexion 



8. Connexion etablie 



Gatekeeper 




Terminal H .323 
de Beatrice 



Figure 3.18 

Etapes de localisation d'un utilisateur 
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On considere qu' Alain souhaite joindre Beatrice. Pour communiquer avec le terminal de 
Beatrice, il procede de la fa^on suivante : 

1. Le terminal d' Alain envoie un message a son gatekeeper lui indiquant qu'il souhaite 
entrer en relation avec Beatrice. 

2. Le gatekeeper d' Alain verifle qu'il est autorise a emettre cet appel. Si c'est le cas, il 
n'informe pas encore le terminal d' Alain de cette autorisation mais entreprend de 
localiser Beatrice. La reponse qui sera envoyee plus tard au terminal d' Alain contien- 
dra a la fois 1' autorisation d' appel et la localisation de l'appele. Le gatekeeper 
d' Alain envoie un message de localisation LRQ vers le gatekeeper de Beatrice. 

3. Le gatekeeper de Beatrice verifle dans sa base de donnees qu'il a bien un enregistre- 
ment valable pour le terminal de Beatrice indiquant sa position courante (c'est-a-dire 
son adresse IP). II retourne alors cette position au gatekeeper d' Alain par un message 
LCF. 

4. Le gatekeeper d' Alain informe le terminal d' Alain de son autorisation a effectuer la 
communication sollicitee. Cela se fait par un message ACF incluant la position 
courante du terminal de Beatrice dans le reseau. 

5. Le terminal d' Alain peut des lors contacter le terminal de Beatrice (avec un message 
Q.931 setup que la figure ne mentionne pas afln de ne laisser que les messages 
RAS). 

6. Le terminal de Beatrice envoie une demande ARQ a son gatekeeper pour demander 
1' autorisation de prendre cet appel, ainsi que 1' allocation de bande passante neces- 
saire. 

7. Le gatekeeper de Beatrice decide de valider la demande par un message ACF, even- 
tuellement en reduisant la demande de bande passante si les contraintes reseau ou le 
profll de l'utilisateur l'exigent. 

8. La communication est etablie (en principe avec un message Q.931 alerting indi- 
quant que le poste sonne puis un message CONNECT indiquant que le correspondant a 
repondu a 1' appel). 

Le protocole H.245, la signalisation de controle de connexion 

Le protocole H.245 gere l'ouverture du canal de controle, l'etablissement du canal de 
transmission, la negotiation des parametres (comme le codec utilise) et le controle de flux 
ainsi que la fermeture du canal de controle. Comme pour le protocole Q.931, tous les 
messages H.245 ne sont pas exploitables dans le protocole H.323, qui n'en utilise qu'une 
faible proportion. 

Initialement, les messages H.245 ne devaient etre diffuses qu'apres le message Q.931 
setup. Pour optimiser les temps d'etablissement d'une communication, les versions 
suivantes de H.323 ont fortement suggere que les echanges H.245 s'etablissent en paral- 
lele ou meme avant le message Q.931 setup. 
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Le message TCS 

Le message TCS (TerminalCapabilitySet) est obligatoirement le premier envoye dans 
le canal H.245. II indique les capacites du terminal qui emet ce message, notamment le 
type de media (audio, video, donnees) et les codecs qu'il supporte. 

Chaque terminal envoie la liste de ses capacites, generalement par ordre de preference, 
dans un message TCS. A reception, un message d'acquittement TerminalCapacity- 
SetAck est retourne. 

La figure 3.19 illustre les echanges de capacites entre deux terminaux. 



Figure 3.19 
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Le message TCS comporte une table, appelee capability table, mentionnant tous les 
parametres supportes. Les combinaisons de parametres possibles sont speciflees dans un 
descripteur, appele capability descriptor. 

Par exemple, le terminal peut avoir les capacites soit pour la gestion d'une conversion 
audio avec un codec offrant une excellente qualite, soit pour disposer de 1' audio et de la 
video, le tout avec une qualite degradee. Un seul capability descriptor est retenu par 
le correspondant pour communiquer. En confrontant les parametres supportes par chacun 
des deux terminaux, des choix communs sont effectues. 



Le message MSD 

Le protocole H.323 ne repose pas sur un modele de type maitre-esclave. Cependant, dans 
certaines situations conflictuelles entre deux entites equivalentes, il devient necessaire de 
determiner une entite qui impose ses choix a 1' autre. 

Par exemple, pour determiner quelle MCU va etre utilisee si les terminaux ont chacun un 
equipement different pour jouer ce role, il est necessaire d'arbitrer. Cela s'effectue au 
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moyen du message MSD (MasterSlaveDetermination), qui doit etre acquitte par le 
recepteur par un message MasterSlaveDeterminationAck. En fait, la determination 
du maitre peut s'operer prealablement, lors du message TCS, bien qu'il existe un 
message speciflque pour cela. 

La determination du maitre et de l'esclave s'effectue au terme d'une negotiation. Cela 
conforte le fait que les terminaux de 1' architecture H.323 sont fondamentalement equiva- 
lents, lis ne sont pas arbitres par une entite superieure, mais, dans certains cas, la designa- 
tion d'un terminal maitre permet de trancher entre les directives a prendre et d'eviter 
ainsi des conflits entre terminaux. 

Le message OLC 

Le message OLC (OpenLogicalChannel) permet d'ouvrir un canal de signalisation de 
controle (on dit aussi canal logique). Celui-ci indique le type de donnees multimedias 
transmis et les codecs utilises. 

L'ouverture d'un canal logique se fait generalement sur un port TCP, mais peut tout aussi 
bien s'effectuer en UDP. Comme le canal n'est pas bidirectionnel, chaque terminal doit 
avoir un canal logique en utilisant le message OpenLogicalChannel. Ce message assi- 
gne un identiflant de session (session ID) a la communication. Par defaut, la session 1 est 
attribute a une communication audio, la session 2 a une communication video et la 
session 3 a une communication de donnees. 

Le message doit en outre utiliser un codec selectionne parmi ceux que le correspondant a 
prealablement mentionnes dans la requete TCS. Un message d'acquittement OpenLogi- 
calChannelAck valide la requete. 

La figure 3.20 illustre l'ouverture d'un canal de controle entre deux terminaux. 

Figure 3.20 
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Cette etape etant optionnelle (voir la procedure de FastConnect), il est possible de trans- 
porter les messages H.245 dans des messages H.225.0 (voir la procedure de H.245 tunneling). 

Les messages CLC et ESC 

Deux messages distincts sont necessaires pour cloturer un canal de signalisation de 
controle : le message CLC (CloseLogicalChannel), qui attend un acquittement 
CloseLogicalChannelAck, et le message ESC (EndSessionCommand), qui doit etre 
emis par chaque intervenant. 

La figure 3.21 illustre la fermeture d'un canal de controle entre deux terminaux. 

Figure 3.21 
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Bien souvent, les constructeurs ne tiennent pas compte de la fermeture du canal de 
controle et se contentent d'un message de signalisation Q.931 pour indiquer la terminaison 
d'appel. 

Les autres protocoles 

Bien d'autres protocoles sont utilises dans la specification H.323. 

Le tableau 3.2 recapitule les principaux protocoles presents dans H.323. 



Protocole 

RTP (Real-time 
Transport Protocol) 

RTCP (Real-time 
Transport Control 
Protocol) 



Tableau 3.2 - Principaux protocoles de H.323 

Description 

Assure I'horodatage des paquets aii niveau de I'emetteur pour permettre la synchronisation 
au niveau du recepteur. 

Retourne des informations statistiques sur la qualite de la connexion du recepteur vers 
I'emetteur, afin que ce dernier puisse adapter ses envois en consequence. 
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Protocole 

H.235.X 

H.450.X 



H.460.X 

X.680 
X.691 
T.120 

T.38 

V.150.1 

H.26x 

H.510 



Tableau 3.2 - Principaux protocoles de H.323 (suite) 

Description 

Les protocoles de securite a utiliser dans un systeme H.323 sont deer its dans les docu- 
ments H.235 sous dix sections referencees de H. 235.0 a H. 235.9. 

La serie H. 450.x definit un ensemble de protocoles pour la mise en oeuvre de services 
supplementaires. Mors que la specification H. 450.1 propose simplement un cadre 
generique, les suivantes specifient la fourniture de services divers, comme le transfert 
d'appel (H.450.2), la mise en attente d'appel (H.450.4), I'indication d'un appel pendant 
un autre appel (H.450.6), la presentation de I'appelant (H.450.8), le renvoi d'appel 
(H.450.9), etc. 

La serie H. 460.x definit un ensemble d'extensions qu'il est possible d'apporter au protocole 
de base. Par exemple, le document H. 460.9 detaille comment un point de terminaison peut 
envoyer des informations de qualite de service pour permettre a ce dernier d'optimiser le 
routage des appels. 

C'est le document de reference pour la syntaxe ASN.1 qui est utilisee dans le codage des 
donnees H.323. 

Definit les regies d'encodage des paquets (Packet Encoding Rules) pour la transmission 
reseau. 

Specification pour I'echange de donnees lors des conferences, off rant lafiabilite des exchan- 
ges et I'interoperabilite entre les constructeurs, tout en preservant une independance vis-a- 
vis du type de reseau utilise. 

Definit la maniere de relayer les communications pour les fax. 

Definit la maniere de relayer les communications pour les modems. 

Ces documents detaillent les codecs normalises pour les transmissions multimedias. Les 
deux plus utilises sont H.261 pour le codage video a debits multiples de 64 Kbit/s par 
seconde et H.263 pour le codage video a faible debit. 

Decrit un support pour la mobilite des utilisateurs en leur fournissant des services analo- 
gues quel que soit le terminal qu'ils utilisent. 



Exemple de scenario d'une communication complete 

Une communication complete inclut 1' ensemble des messages envoyes pour initier, 
etablir et terminer une communication entre deux correspondants. 

On considere une zone H.323 (il y a done presence d'un gatekeeper pour le controle 
d' admission des terminaux). On suppose que la signalisation se fait en mode direct 
(seuls les messages de signalisation RAS sont routes vers le gatekeeper). On suppose 
egalement que ces terminaux se sont prealablement enregistres aupres du gatekeeper et 
qu'ils dependent tous deux d'un meme gatekeeper (la localisation n'est done pas a entre- 
prendre). 

Les optimisations que nous presentons plus loin dans ce chapitre ne sont pas prises en 
compte arm de simplifier la comprehension des differentes etapes. Nous verrons toutefois 
que, dans la pratique, 1' implementation de ces ameliorations demeure indispensable. 
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La figure 3.22 illustre un exemple de communication complete entre deux terminaux 
H.323. Les etapes successives qui caracterisent cet echange sont les suivantes : 



Figure 3.22 
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1. Connexion (protocole H.225.0). Avant de contacter son correspondant, l'appelant 
s'assure d'etre autorise a emettre cet appel aupres du gatekeeper (RAS), puis envoie 
sa requete au terminal appele (Q.931). Celui-ci s'assure a son tour aupres du gatekee- 
per d'avoir le droit d'effectuer cette communication (RAS). Pour les deux correspon- 
dants, on considere le cas ou 1' appel est autorise pour pouvoir poursuivre. Des que le 
terminal appele re^oit la permission, il envoie des messages alertant l'appelant de sa 
disponibilite (Q.931) et lui conflrmant que la connexion peut debuter (Q.931). 

2. Negociation des parametres et ouverture du canal de controle (protocole H.245.0). 
Commence un echange reciproque de messages pour determiner les parametres a 
mettre en place lors de la communication (H.245). A ce stade, il serait possible de 
negocier, par exemple, le choix des flux desires (voix, video ou les deux), le choix 
des codecs ainsi que les debits souhaites. Le canal de signalisation de controle est 
ainsi ouvert. 

3. Debut de la communication (RTP/RTCP). La communication audio et video peut 
commencer en laissant transiter les medias. 

4. Fermeture des canaux de signalisation. Lorsqu'un correspondant met fin a 1' appel 
(en raccrochant son combine, par exemple), la communication est cloturee par un 
message de signalisation fermant le canal Q.931. Ensuite, chacun des intervenants 
indique au gatekeeper la terminaison de 1' appel, ce qui permet a ce dernier de deter- 
miner la duree de 1' appel a des fins de statistiques, journalisation ou facturation ou 
d'allouer la bande passante liberee a d'autres appels. 



Fonctionnalites avancees de H.323 

Cette section detaille quelques fonctionnalites qui ont ete ajoutees a la premiere recom- 
mandation de H.323 et sont devenues de facto des complements non obligatoires mais 
fortement recommandes. 

La procedure Early H.245 

En principe, le tunnel H.245 permettant la negociation d' appel n'est etabli qu'apres le 
message H.225.0/Q.931 setup. Ce message contient les parametres permettant la mise 
en place du canal H.245. 

L'idee a la base de ce choix est qu'il ne sert a rien de negocier des parametres de commu- 
nication tant que la personne appelee n'a pas accepte 1' appel. Les negociations effectuees 
s'avereraient totalement inutiles si la communication ne devait pas etre etablie. Si 1' appel 
aboutit effectivement, les negociations de parametres qui interviennent entre les interve- 
nants retardent sensiblement le temps d'etablissement de la communication. Par consequent, 
anticiper ces actions se releve pratique. 

Avec la procedure Early H.245, il est possible d'avancer l'etablissement du canal H.245. 
Pour cela, il faut inclure les parametres de mise en place du canal H.245 dans un message 
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precedant la requete setup. Typiquement, on utilise la requete alerting pour donner ces 
informations. 

Des que cette derniere est re^ue, l'etablissement du canal H.245 peut commencer paral- 
lelement a la signalisation H.225.0. Globalement, cela accelere sensiblement l'etape de 
negociation des parametres effectuee avec le protocole H.245, et l'appel est plus rapi- 
dement etabli. 

Cette optimisation particulierement utile est souvent disponible en complement de la 
procedure FastConnect. 

La procedure FastConnect 

En principe, le canal H.245 permettant la negociation des parametres d'appel est neces- 
saire pour l'etablissement d'une communication. On constate cependant que l'ouverture 
d'un tunnel de controle H.245 est relativement longue et penalisante pour l'etablissement 
d'une communication (de l'ordre de 15 a 30 secondes dans 1' implementation de la 
premiere version de H.323, ce qui est excessivement long). 

Tous les parametres negocies par ce canal ne sont pas indispensables. Partant de ce 
constat, a partir de la version 2 de la recommandation H.323, l'ouverture du canal H.245 
a ete simpMee et rendue optionnelle, tandis que d'autres moyens ont ete proposes pour 
echanger les parametres negocies par ce tunnel. 

Avec la procedure FastConnect, il est possible d'inclure dans 1' invitation d'appel des 
informations de canal de controle. De cette maniere, l'etablissement d'un appel peut se 
faire en seulement deux messages. 

L' inconvenient de cette methode est qu'elle ne permet pas la transmission d' informations 
DTMF. II s'agit neanmoins d'une optimisation indispensable a l'etablissement d'appels 
dans des delais raisonnables. 

La procedure H.245 tunneling 

Pour chaque appel, il est en principe necessaire d'avoir deux connexions separees : l'une 
pour les messages de signalisation d'appel Q.931, 1' autre pour la mise en place du canal 
de controle H.245. 

Avec la procedure H.245 tunneling, il est possible de n'avoir qu'un seul canal. Pour cela, 
les messages de controle H.245 doivent etre encapsules dans des messages H.225.0. 

La securite 

Absents de la premiere version du protocole, les mecanismes de securite ont ete ajoutes 
des la seconde avec la recommandation H.235. 

En juin 2006, a 1' occasion de la sixieme version du protocole, la recommandation H.235 
a ete totalement remaniee et restructuree autour d'une serie de documents numerates de 
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H.235.0 a H.235.9. Ces documents detaillent les mecanismes de securite ajoutes a la 
norme en les repartissant en plusieurs volets, notamment les suivants : 

• Authentication. Ce mecanisme permet de s'assurer de l'identite des correspondants. 
Tout utilisateur doit s'authentifier aupres du gatekeeper avant d'etre autorise a emettre 
ou recevoir un appel. C'est egalement indispensable pour garantir la bonne gestion des 
facturations d'appels. 

• Controle d'integrite. Ce mecanisme permet de s'assurer que les donnees sont trans- 
mises sans avoir ete alterees ni corrompues pendant leur transfert. 

• Confldentialite. Cet aspect couvre les methodes de cryptage de donnees empechant les 
ecoutes clandestines d'une communication. 

• Non-repudiation. Ce mecanisme permet de s'assurer de la provenance d'un message 
(empechant l'emetteur de nier ulterieurement son envoi). 

Le protocole H.323 supporte aussi la securisation des echanges multimedias via le proto- 
col SRTP (Secure RTP). 

Gatekeeper alternatif et gatekeeper affecte 

Dans l'architecture H.323, les gatekeepers jouent un role preponderant et sont relative- 
ment souvent sollicites par les autres equipements, ce qui en fait des entites particulierement 
sensibles. 

Deux mecanismes, appeles gatekeeper alternatif et gatekeeper affecte, ont ete prevus 
pour ameliorer la stabilite et la robustesse du reseau, meme en cas de panne d'un gate- 
keeper. 

Gatekeeper alternatif 

Si un gatekeeper tombe en panne, un autre, le gatekeeper alternatif, peut prendre dynami- 
quement le relais et traiter les appels en cours. Cette possibilite a ete introduite dans la 
version 2 du protocole H.323. Les terminaux qui la supportent peuvent basculer vers un 
nouveau gatekeeper des qu'ils detectent une panne de leur gatekeeper initial. 

Les gatekeepers ainsi places en redondance procurent une meilleure stabilite au reseau. 
En outre, il devient possible d'effectuer de la repartition de charge afin qu'un gatekeeper 
trop sollicite puisse se faire relayer par un autre. 

Pour les operateurs, cette fonctionnalite assure une meilleure disponibilite et une conti- 
nuity de services, meme en cas de defaillances materielles ou logicielles. 

Gatekeeper affecte 

Avec ce mecanisme, chaque terminal dispose par defaut d'un gatekeeper de reference, 
aupres duquel il cherche systematiquement et preferentiellement a s'enregistrer. Ce gate- 
keeper est appele gatekeeper affecte. Si, a la suite d'une panne, d'une saturation ou pour 



Theorie de la TolP 



Parte I 



toute autre raison, la connexion avec celui-ci s'avere impossible, le terminal doit basculer 
vers un gatekeeper alternatif pour continuer a communiquer normalement. 

Tout en etant sous le controle d'un autre gatekeeper que celui affecte, le terminal conti- 
nue a surveiller periodiquement son gatekeeper affecte afln de verifier sa disponibilite. 
En cas d'activite detectee, le terminal se reoriente vers lui pour s'y enregistrer. Cela 
permet de repartir au mieux les utilisateurs entre les gatekeepers et par voie de conse- 
quence de disposer d'une meilleure gestion des ressources disponibles. 

Cette fonctionnalite a ete introduite dans la version 6 du protocole H.323. 



Conclusion 



Le protocole H.323 a constitue un tournant dans l'histoire de la telephonie sur IP. 
Symbole de 1' unification des fonctionnalites de signalisation pour la telephonie dans un 
reseau IP, il a ete le premier standard propose et adopte massivement par les industriels. 
II a ensuite conquis des marches considerables qui ont rendu toute concurrence difficile a 
soutenir. 

Mais s'il propose une reponse a la signalisation, le protocole souffre d'inconvenients 
contraignants pour supporter le passage a l'echelle au niveau mondial. Son exploitation 
dans le cadre du reseau Internet se heurte a la superposition d'une architecture centralisee 
dans un modele totalement distribue. 

En outre, le protocole demeure complexe et lourd a mettre en place. Pour combler ces 
faiblesses, les implementations de H.323 par les industriels et les editeurs de logiciel ont 
parfois du s'autoriser quelques ecarts par rapport a la definition stricte donnee dans les 
recommandations de 1'UIT. Malheureusement, ces optimisations proprietaries different 
selon les equipements, si bien qu'au lieu de jouer un role federateur, comme le protocole, 
elles ont fait perdre l'interoperabilite entre les plates-formes de constructeurs distincts. 

Enfln, la compatibilite ascendante exigee par H.323 oblige tous les constructeurs et four- 
nisseurs de services a implementer 1' ensemble des mecanismes pour etre compatibles 
entre eux, y compris ceux proposes dans les versions precedentes du protocole. Par 
exemple, pour etre compatible avec la version 6 du protocole, un equipement doit neces- 
sairement savoir communiquer avec un equipement exploitant une implementation de 
Tune des versions 1 a 5. Autrement dit, le protocole est constamment enrichi sans jamais 
etre veritablement epure. 

Aujourd'hui, H.323 tend a disparaitre et a se marginaliser. Bien souvent, sa presence 
n'est justiflee que pour des raisons historiques. Le protocole qui devrait s'imposer 
comme son rempla^ant, SIP, a pour sa part ete entierement congu selon la philosophic du 
monde IP. 
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Le protocole SIP 



La telephonie sur IP se situe a la jonction de deux mondes : celui des telecoms et celui 
d' Internet. Le premier a invente le service, le second cherche a se l'approprier. II etait 
done naturel que des intervenants de ces deux mondes soient a 1'origine de la conception 
du protocole de signalisation qui en permet la gestion. 

Cependant, au lieu de travailler en commun, chaque acteur de la normalisation a tente de 
faire valoir sa vision de la telephonie au sein de son propre protocole. Cote telecoms, le 
protocole H.323 de l'UIT propose une architecture centralisee qui rappelle les origines 
de la telephonie traditionnelle. Cote Internet, le protocole SIP de 1'IETF propose des 
mecanismes tres proches de ceux des protocoles en vigueur sur Internet. 

Le chapitre precedent a presente H.323. Le present chapitre detaille le protocole SIP. 

La standardisation SIP (Session Initiation Protocol) 

L'lETF s'interesse a la telephonie sur IP et travaille a la mise au point d'un protocole 
charge de la gestion de sa signalisation depuis 1995. 

En 1997, la premiere version de ce protocole, nomme SIP, est devoilee au public. Entre- 
temps, l'UIT lui avait vole la vedette avec H.323 , sorti en 1996, qui avait beneficie de la 
faveur des industriels et dont les implementations logicielles, notamment NetMeeting de 
Microsoft, assuraient la celebrite. 

Pendant plusieurs annees, 1'IETF n'a pas ete un acteur visible dans le domaine de la ToIP. 
Plus le protocole tardait a voir le jour, plus le handicap par rapport a son concurrent 
H.323 s'amplifiait. Si le protocole H.323 possede aujourd'hui la maturite que lui confe- 
rent son avance et ses nombreuses experimentations, sa gestion demeure laborieuse et 
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reste peu adaptee au monde Internet. Or c'est a ce niveau qu'intervient SIP, dont la force 
principale vient de son extreme simplicity, meme a grande echelle. 

Le protocole SIP a ete congu pour s' adapter a Internet, en particulier pour que le reseau 
supporte des montees en charge du nombre d'utilisateurs. Pour cela, l'architecture SIP 
repose sur plusieurs serveurs distincts, qui distribuent la charge du reseau en communi- 
quant entre eux, un peu a la maniere des serveurs DNS sur Internet. Lorsque le nombre 
d'utilisateurs croit, il suffit d'ajouter des serveurs disposant de fonctions dediees pour 
collaborer avec ceux deja en place. 

Cette approche se revele hautement evolutive et flexible puisque de nouvelles fonction- 
nalites peuvent a tout moment etre deployees, sans avoir a modifier les composants 
existants. 



Historique 



SIP (Session Initiation Protocol) a ete normalise par le groupe de travail WG MMUSIC 
(Work Group Multiparty Multimedia Session Control) de 1'IETF. La version 1 est sortie 
en 1997, et une seconde version majeure a ete proposee en mars 1999 (RFC 2543). Cette 
derniere a elle-meme ete largement revue, completee et corrigee en juin 2002 
(RFC 3261). Des complements au protocole ont ete dermis dans les RFC 3262 a 3265. 

SIP est au sens propre un protocole de signalisation hors bande pour l'etablissement, le 
maintien, la modification, la gestion et la fermeture de sessions interactives entre utilisa- 
teurs pour la telephonie et la videoconference, et plus generalement pour toutes les 
communications multimedias. 

Le protocole n' assure pas le transport des donnees utiles, mais a pour fonction d'etablir 
la liaison entre les interlocuteurs. Autrement dit, il ne vehicule pas la voix, ni la video, 
mais assure simplement la signalisation. II se situe au niveau de la couche applicative du 
modele de reference OSI et fonctionne selon une architecture client- serveur, le client 
emettant des requetes et le serveur executant en reponse les actions sollicitees par le 
client. 

SIP fournit des fonctions annexes evoluees, comme la redirection d'appel, la modifica- 
tion des parametres associes a la session en cours ou l'invocation de services. En fait, SIP 
ne fournit pas 1' implementation des services, mais propose des primitives generiques 
permettant de les utiliser. De cette maniere, 1' implementation des services est laissee 
libre, et seul le moyen d'acceder aux services est fourni. 



Compatibilite 



L'un des grands atouts de SIP est sa capacite a s'integrer a d'autres protocoles standards 
du monde IP. En tant que standard ouvert, il offre un service modulaire, prevu pour fonc- 
tionner avec differentes applications, telles que la telephonie, la messagerie instantanee, 
la videoconference, la realite virtuelle ou meme le jeu video. 
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En fait, plus qu'une simple compatibility, c'est la possibility de l'utiliser en conjonction 
avec d'autres protocoles qui caracterise SIP. Le protocole s'insere comme une partie d'un 
ensemble plus generique, intitule Internet Multimedia Conferencing Suite. A 1' image de 
H.323, SIP est peu a peu devenu un protocole dit parapluie, qui encadre et rassemble 
plusieurs autres protocoles. 

SIP peut notamment se deploy er ou s'integrer aux protocoles suivants : 

RTP (Real-time Transport Protocol), RFC 3550, qui se charge du transport des flux 
temps reel. 

RTCP (Real-time Transport Control Protocol), RFC 3550, qui fournit des informations 
dynamiques sur l'etat du reseau. 

RTSP (Real-Time Streaming Protocol), RFC 2326, pour controler la diffusion de flux 
multimedias en temps reel. 

SDP (Session Description Protocol), RFC 2327, qui fournit la description d'une 
session, c'est-a-dire les parametres utilises dans une communication SIP. 

SAP (Session Advertisement Protocol), RFC 2974, pour les communications multi- 
cast, qui permet d'ajouter les specifications d'une nouvelle session. 

MIME (Multipurpose Internet Mail Extension), RFC 2045, standard pour les descriptions 
de contenus, utilise sur Internet. 

RSVP (Resource reSerVation Protocol), RFC 2205, pour obtenir des garanties de 
qualite de service et effectuer des reservations de ressources. 

HTTP (HyperText Transfer Protocol), RFC 2616, pour le traitement des pages Web sur 
Internet (on peut inclure des adresses SIP directement dans des pages Web). 

MGCP (Media Gateway Control Protocol), RFC 3435, pour le controle des passerelles 
assurant la connectivity entre un reseau IP et un reseau telephonique. 

Tous ces protocoles sont d'une nature differente de celle de SIP, et ils n'interferent pas 
avec la signalisation. Leur utilisation conjointe est possible, voire recommandee pour 
certains d' entre eux. 

Cela dit, aucun d'eux n'est indispensable au bon fonctionnement de SIP, qui reste totale- 
ment independant a leur egard et autorise a priori n'importe quel autre protocole. Dans la 
pratique, nous verrons cependant que SIP est classiquement utilise avec les memes proto- 
coles. 



Modularity 



Comme explique precedemment, le protocole SIP se veut modulaire. Son objectif est de 
constituer une brique de base pouvant se combiner avec le maximum d'autres protocoles. 
C'est la raison pour laquelle il a ete con^u d'une maniere independante de la couche de 
transport. 
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Les protocoles TCP et UDP sont done tous deux supportes pour 1' envoi de messages SIP. 
UDP est generalement preferable pour laisser a 1' application le controle des retransmis- 
sions de messages, et done l'enchamement des messages. Pour sa part, TCP est prefe- 
rable pour la traversee de pare-feu, dans la mesure ou les ports utilises avec SIP sont 
dynamiques et ou la notion d'etat de connexion n'existe pas avec UDP. 

Mais il ne s'agit la que de recommandations. Aucune regie n'est fixee, et meme avec 
UDP, il existe des moyens de contourner le fUtrage des pare-feu. 



Simplicite 



SIP affiche une grande simplicite, comme l'atteste la taille de la specification du proto- 
cole, qui ne depasse pas 153 pages dans sa premiere version (RFC 2543) et 269 pages 
dans la seconde (RFC 3261), ce qui reste nettement inferieur aux 763 pages de la specifi- 
cation H.323. 

SIP utilise un langage textuel tres proche des protocoles HTTP et SMTP, ce qui facilite 
son integration a Internet. Par comparaison, le protocole H.323 utilise ASN.l, qui est un 
langage compile. 

Les avantages d'un langage textuel sont les suivants : 

• Les traitements de commandes ne necessitent pas de compilation et sont par consequent 
plus rapidement interpretes. 

• L' implementation de nouveaux services ne necessite pas de compilateur pour inter- 
preter les commandes. 

• II est facile pour les programmeurs d'interpreter a la volee les actions en cours, 
puisqu'elles circulent en clair. La maintenance des services et 1' implementation de 
nouveaux services en sont d'autant facilities. 

La simplicite de SIP en fait un protocole facile a embarquer et un candidat de choix pour 
les composants legers, dotes de capacites reduites, comme les telephones mobiles. Son 
implementation est peu gourmande en ressources de traitement. 

La simplicite de SIP ne l'empeche nullement d'etre veritablement performant. Sa 
souplesse d'utilisation est ainsi l'une de ses caracteristiques principales. II est, par exem- 
ple, possible de modifier une session en cours. Un nouveau participant peut se joindre 
a une conference dynamiquement et facilement. Les modifications de parametres sont 
prises en compte a la volee lors de la communication. De la meme maniere, il est 
possible d'ajouter de la video a une communication audio ou encore de changer de codec 
a tout moment, ce qui simplifie la mise en oeuvre du protocole dans une infrastructure 
quelconque. 

Par ailleurs, l'encodage UTF-8 (Unicode Transformation Format), decrit dans la RFC 
2879, utilise pour les messages SIP permet d'utiliser un jeu universel de caracteres 
Unicode (jeu de caracteres ISO 10646) pour toutes les langues, et done de recourir a 
d'autres caracteres que 1' alphabet occidental. 
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Architecture de SIP 

Contrairement a H.323, largement fonde sur une architecture physique, le protocole SIP 
s'appuie sur une architecture purement logicielle. 

L' architecture de SIP s'articule principalement autour des cinq entites suivantes : 

• terminal utilisateur ; 

• serveur d'enregistrement ; 

• serveur de localisation ; 

• serveur de redirection ; 

• serveur proxy. 

La figure 4.1 illustre de fa^on generique les communications entre ces elements. Un seul 
terminal etant present sur cette figure, aucune communication n'est possible. Nous nous 
interessons en fait ici aux seuls echanges entre le terminal et les services que ce dernier 
est susceptible d'utiliser lors de ses communications. 



Terminal 



CLIENT 





SERVEURS 



Figure 4.1 

Architecture de SIP 
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On peut schematiquement observer qu'il existe deux categories de services : l'un fourni 
au niveau de l'utilisateur (par le terminal), l'autre fourni au niveau des serveurs du 
reseau. Ces derniers sont repartis en deux classes : les serveurs de redirection et proxy, 
qui facilitent le routage des messages de signalisation et jouent le role d'intermediaires, 
et les serveurs de localisation et d'enregistrement, qui ont pour fonction d'enregistrer ou 
de determiner la localisation des abonnes du reseau. 

Terminal 

Le terminal est l'element dont dispose l'utilisateur pour appeler et etre appele. II doit 
done permettre de composer des numeros de telephone. II peut se presenter sous la forme 
d'un composant materiel (un telephone) ou d'un composant logiciel (un programme 
lance a partir d'un ordinateur). 

Le terminal est appele UA (User Agent). II est constitue de deux sous-entites, comme 
illustre a la figure 4.2 : 

• Une partie cliente, appelee UAC (User Agent Client), chargee d'emettre les requetes. 
C'est l'UAC qui initie un appel. 

• Une partie serveur, appelee UAS (User Agent Server), qui est en ecoute, re^oit et traite 
les requetes. C'est l'UAS qui repond a un appel. 

L' association des requetes et des reponses entre deux entites de type UA constitue un 
dialogue. 

Figure 4.2 Requete 

UAC et UAS 



User pN X [^N User 

Agent 1 13 J ) \ip Agent 

Client ^U J ^J Server 



Reponse 

Par analogie, on peut remarquer que la meme chose se produit avec le protocole HTTP 
dans une application Web : un utilisateur exploite son navigateur comme client pour 
envoyer des requetes et contacter une machine serveur, laquelle repond aux requetes du 
client. La difference essentielle par rapport aux applications standards utilisant HTTP est 
qu'en telephonie un terminal doit etre a la fois utilise pour joindre un interlocuteur et 
pour appeler. Chaque terminal possede done la double fonctionnalite de client et de 
serveur. 

Lors de 1' initialisation d'un appel, l'appelant exploite la fonctionnalite client de son 
terminal (UAC), tandis que celui qui re9oit la communication exploite sa fonctionnalite 
de serveur (UAS). 

La communication peut etre cloturee indifferemment par l'User Agent Client ou l'User 
Agent Server. 
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De nombreuses implementations de clients SIP sont disponibles sur les plates-formes les 
plus courantes, Windows, Linux ou Mac. Elles sont le plus souvent gratuites, sous 
licence GPL. 

Parmi les clients SIP les plus reputes, citons notamment les suivants : 

• X-Lite Free 

• Phone Gaim 

• Wengo 

Ces clients SIP disposent de diverses fonctionnalites ameliorees. En choisir un est 
souvent affaire de gout, selon l'ergonomie du logiciel et les caracteristiques souhaitees 
(support d'un codec particulier, support de la messagerie instantanee, etc.). 

Serveur d'enregistrement 

Deux terminaux peuvent communiquer entre eux sans passer par un serveur d'enregistre- 
ment, a la condition que 1' appelant connaisse l'adresse IP de l'appele. Cette contrainte 
est fastidieuse, car un utilisateur peut etre mobile et done ne pas avoir d'adresse IP fixe, 
par exemple s'il se deplace avec son terminal ou s'il se connecte avec la meme identite a 
son travail et a son domicile. En outre, l'adresse IP peut etre fournie de maniere 
dynamique par un serveur DHCP. 

Le serveur d'enregistrement (Registrar Server) offre un moyen de localiser un correspon- 
dant avec souplesse, tout en gerant la mobilite de 1' utilisateur. II peut en outre supporter 
l'authentification des abonnes. 

Dans la pratique, lors de l'activation d'un terminal dans un reseau, la premiere action 
initiee par celui-ci consiste a transmettre une requete d'enregistrement aupres du serveur 
d'enregistrement afin de lui indiquer sa presence et sa position de localisation courante 
dans le reseau. C'est la requete register, que nous detaillons plus loin, que l'utilisateur 
envoie a destination du serveur d'enregistrement. Celui-ci sauvegarde cette position en 
l'enregistrant aupres du serveur de localisation. 

L'enregistrement d'un utilisateur est constitue par l'association de son identifiant et de 
son adresse IP. Un utilisateur peut s'enregistrer sur plusieurs serveurs d'enregistrement 
en meme temps. Dans ce cas, il est joignable simultanement sur l'ensemble des positions 
qu'il a renseignees. 

Serveur de localisation 

Le serveur de localisation (Location Server) joue un role complementaire par rapport au 
serveur d'enregistrement en permettant la localisation de l'abonne. 

Ce serveur contient la base de donnees de l'ensemble des abonnes qu'il gere. Cette base 
est renseignee par le serveur d'enregistrement. Chaque fois qu'un utilisateur s'enregistre 
aupres du serveur d'enregistrement, ce dernier en informe le serveur de localisation. 
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Presque toujours, le serveur de localisation et le serveur d'enregistrement sont imple- 
ments au sein d'une meme entite. On parle alors souvent non pas de serveur de localisa- 
tion, mais de service de localisation d'un serveur d'enregistrement, tant ces fonctionnalites 
sont proches et dependantes. 

Les serveurs de localisation peuvent etre collaboratifs. Le fonctionnement d'un serveur 
d'enregistrement est analogue a celui d'un serveur DNS dans le monde Internet : pour 
joindre un site Internet dont on ne connait que le nom, il faut utiliser un serveur DNS, qui 
effectue la conversion (on parle de resolution) du nom en adresse IP. Ce serveur a 
connaissance d'une multitude d'adresses, qu'il peut resoudre parce qu'elles appartiennent a 
son domaine ou qu'il a la capacite d'apprendre dynamiquement en fonction des echanges 
qu'il voit passer. Des qu'un nom lui est inconnu, il fait appel a un autre DNS, plus important 
ou dont le domaine est plus adequat. De la meme maniere, les serveurs de localisation 
prennent en charge un ou plusieurs domaines et se completent les uns les autres. 

Serveur de redirection 

Le serveur de redirection (Redirect Server) agit comme un intermediaire entre le terminal 
client et le serveur de localisation. II est sollicite par le terminal client pour contacter le 
serveur de localisation afln de determiner la position courante d'un utilisateur. 

L' appelant envoie une requete de localisation d'un correspondant (il s'agit en realite d'un 
message d' invitation, qui est interprets comme une requete de localisation) au serveur de 
redirection. Celui-ci joint le serveur de localisation afin d'effectuer la requete de localisa- 
tion du correspondant a joindre. Le serveur de localisation repond au serveur de redirection, 
lequel informe l'appelant en lui fournissant la localisation trouvee. Ainsi, l'utilisateur n'a 
pas besoin de connaitre 1' adresse du serveur de localisation. 

Serveur proxy 

Le serveur proxy (parfois appele serveur mandataire) permet d'initier une communica- 
tion a la place de l'appelant. II joue le role d' intermediaire entre les terminaux des inter- 
locuteurs et agit pour le compte de ces derniers. 

Le serveur proxy remplit les differentes fonctions suivantes : 

• localiser un correspondant ; 

• realiser eventuellement certains traitements sur les requetes ; 

• initier, maintenir et terminer une session vers un correspondant. 

Lorsqu'un utilisateur demande a un serveur proxy de localiser un correspondant, ce 
dernier effectue la recherche, mais, au lieu de retourner le resultat au demandeur (comme 
le ferait un serveur de redirection), il utilise cette reponse pour effectuer lui-meme 
1' initialisation de la communication en invitant le correspondant a ouvrir une session. 

Bien que fournissant le meme type de service de localisation qu'un serveur de redirec- 
tion, un serveur proxy va done plus loin que la simple localisation en initiant la mise en 
relation des correspondants de fa^on transparente pour le client. II peut acheminer tous 
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les messages de signalisation des terminaux, de 1' initialisation de la communication a sa 
terminaison, en passant par sa modification. En contrepartie, le serveur proxy est une 
entite beaucoup plus sollicitee que le serveur de redirection, et done plus lourde. 

Chaque terminal peut et devrait en principe disposer d'un tel serveur sur lequel se reposer 
pour interpreter, adapter et relay er les requetes. En effet, le serveur proxy peut reformuler 
une requete du terminal UAC afm de la rendre comprehensible par le serveur auquel s'adresse 
l'UAC. Cela accroit la souplesse d'utilisation du terminal et simplifle son usage. 

Les serveurs proxy jouent aussi un role collaboratif, puisque les requetes qu'ils vehiculent 
peuvent transiter d'un serveur proxy a un autre, jusqu'a atteindre le destinataire. Notons 
que le serveur proxy ne fait jamais transiter de donnees multimedias et qu'il ne traite que 
les messages SIP. 

Le proxy est une entite tres souvent utilisee dans la pratique. Par analogie avec 1' architec- 
ture illustree a la figure 4.3, symbolisant l'organisation des communications, on parle 
souvent du trapeze SIP pour designer l'ensemble forme par ces quatre entites. 

Serveur proxy Serveur proxy 

d'Albert de Brigitte 





Terminal 
de Brigitte 



Figure 4.3 

Le trapeze SIP 



On distingue deux types de serveurs proxy : 

• Proxy statefull, qui maintient pendant toute la duree des sessions l'etat des connexions. 

• Proxy stateless, qui achemine les messages independamment les uns des autres, sans 
sauvegarder l'etat des connexions. 

Les proxy stateless sont plus rapides et plus legers que les proxy statefull, mais ils ne 
disposent pas des memes capacites de traitement sur les sessions. 

Mise en place de serveurs SIP 

Plusieurs logiciels implemented les diverses fonctionnalites des serveurs SIP, notam- 
ment les suivants : 

• SIP Express Router (http://www.iptel.org/ser/) ; 

• Party sip SIP Proxy Server (http://www.nongnu.org/partysip/partysip.html). 
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Ces deux logiciels libres, respectivement sous licence GPL et LGPL, fonctionnent exclu- 
sivement sur plate-forme Linux. 

Leur nom est en fait trompeur. Ces deux logiciels sont capables de fournir bien d'autres 
services que le routage ou la seule fonction de serveur proxy. lis peuvent etre utilises 
simultanement comme serveurs de localisation, d'enregistrement, de redirection et de 
proxy. En outre, ils peuvent delivrer plusieurs services complementaires, comme 
rauthentification (avec support de Diameter ou de Radius) ou la creation de journaux 
d'activite (en les couplant a une base SQL ou PostgresQL, par exemple). 

L' installation de ces logiciels est modulaire. Les fonctionnalites qui enrichissent le 
serveur SIP de base sont disponibles sous forme de plug-in ou d' add-on. II est done 
necessaire de lancer quelques recherches afln de recuperer les modules que Ton souhaite 
et les installer separement. Si 1' installation de ces plug-in peut se reveler delicate, le logiciel 
gagne en souplesse et evolutivite grace a eux. 

Une solution payante et proprietaire de Cisco, Cisco SIP Proxy Server (http://www.cisco.com/ 
univercd/cc/td/doc/product/voice/sipproxy/), peut egalement etre installee. 

Se connecter a des reseaux non-IP 

SIP a ete con^u initialement pour les reseaux a commutation de paquets de type IP, mais 
ses utilisateurs peuvent aussi joindre des terminaux connectes a des reseaux de nature 
differente. 

Pour cela, il est necessaire de mettre en place des passerelles (gateways), assurant la 
conversion des signaux d'un reseau a un autre. On se retrouve dans le cas de figure 
evoque au chapitre precedent pour le protocole H.323, et nous verrons plus loin que le 
protocole MGCP propose une maniere de gerer ces fonctionnalites. 

L'appel dans l'autre sens, e'est-a-dire d'un reseau non-IP vers un reseau a commutation 
de paquets, est tout aussi envisageable, a la seule condition que le terminal appelant 
dispose de la capacite d'entrer l'adresse de son correspondant SIP. 

Cette adresse n'est generalement pas constitute uniquement de numeros, alors que la 
majorite des telephones traditionnels actuels sont depourvus de clavier. Plusieurs possi- 
bilites permettent de contourner cette difflculte, notamment la reconnaissance audio, la 
saisie d'une adresse a la maniere d'un SMS ou l'attribution de numeros aux correspondants 
SIP. 



L'adressage SIP 

L'objectif de l'adressage est de localiser les utilisateurs dans un reseau. C'est une des 
etapes indispensables pour permettre a un utilisateur d'en joindre un autre. 

Pour localiser les utilisateurs, il faut pouvoir les identifier de maniere univoque. SIP propose 
des moyens tres performants pour nommer les utilisateurs, grace au concept d'URI, classique 
sur Internet, que nous allons detailler avant de voir son utilisation par SIP. 
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URI (Universal Ressource Identifier) 

Un URI definit une syntaxe permettant de designer de maniere unique, formelle et 
normalisee une ressource, qu'il s'agisse d'un document textuel, audio, video ou plus 
generalement d'une entite logique ou physique. 

Une ressource decrite par un URI peut etre deplacee ou meme supprimee. L'URI corres- 
pondant n'en conserve pas moins de maniere permanente la valeur descriptive de la 
ressource. 

Considerons un exemple. Deux personnes portant le meme nom de famille et le meme 
prenom sont susceptibles d'etre confondues si on les recherche dans un annuaire. En 
plus du nom de la personne, qui peut etre partage par d'autres, son age, sa profession 
ou sa localisation sont des parametres susceptibles d'evoluer et qui ne constituent 
done pas des proprietes discriminantes. L' attribution d'un identifiant unique a chaque 
individu assure une identite unique et permet de le differencier des autres avec certi- 
tude. 

C'est, par analogie, toute la vocation d'un numero de Securite sociale. A la syntaxe pres, 
un numero de securite sociale est une forme d'URI. Une adresse e-mail est egalement 
une forme d'URI. 

La figure 4.4 illustre quelques exemples d'attributs non discriminants et discriminants 
qui peuvent constituer ou non des URI. 
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Parametres non discriminants et discriminants 
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Un URI est forme d'une chaine de caracteres. Sa syntaxe a ete definie au CERN (Centre 
europeen pour la recherche nucleaire) de Geneve, par Tim Berners-Lee des 1989, dans le 
cadre du systeme d'hyperliens (liens hypertextes) qu'il proposait la meme annee. Cette 
syntaxe a ete normalisee par 1'IETF en aout 1998 dans la RFC 2396 puis revisee de 
nombreuses fois, notamment dans la RFC 2396bis, et reprise en Janvier 2005 dans la 
RFC 3986. 

Tim Berners-Lee est considere comme l'inventeur du World-Wide Web. C'est lui qui a 
congu le premier serveur HTTP et le premier navigateur Web, qu'il baptisa « Worldwi- 
de Web » apres avoir pense l'appeler « Information Mesh » ou encore « Information 
Mine ». II a refuse de nombreuses propositions d'embauches emanant d'importants grou- 
pes industriels pour fonder en 1994 et diriger depuis le consortium W3C (World-Wide 
Web). Cette instance est chargee de superviser les nouvelles normes mises en oeuvre dans 
Internet arm de permettre son evolution et de garantir son inter operabilite. Avec plus de 
500 membres, il regroupe les plus gros editeurs du secteur des hautes technologies, parmi 
lesquels Microsoft, Sun et IBM. 

Bien qu'etant un consortium, le W3C n'a pas le pouvoir de normaliser des protocoles. 
Ses recommandations ont cependant un impact important et ont tendance a etre suivies 
par 1' ensemble des acteurs du marche. 

Les URL (Uniform Ressource Locator), que Ton manipule couramment dans l'adressage 
Web pour joindre un site Internet, constituent un sous-ensemble des URI. Elles ont pour 
fonction de specifier une localisation relative a une ressource (par exemple www.ietf.org), 
ainsi que la methode permettant d'y acceder (par exemple http, ftp, etc.). 

A la difference d'un URI, une URL se contente d'apporter une localisation et non une 
definition de la ressource. Ainsi, un meme document peut se trouver a deux emplace- 
ments differents, done a deux URL differentes dans le reseau Internet, alors qu'il fait 
reference a une meme ressource. 



Format des adresses SIP 

Tout utilisateur SIP dispose d'un identifiant unique. Cet identifiant constitue l'adresse de 
l'utilisateur permettant de le localiser. 

Le format d'une adresse SIP (ou URL SIP) respecte la RFC 3986 (nommee Uniform 
Resource Identifier: Generic Syntax) et se presente sous la forme illustree a la 
figure 4.5. 



Figure 4.5 

Syntaxe d'une adresse SIP 



sip : identifiant[:mot_de_passe](g)serveur[?parametres] 



Les parties entre crochets sont optionnelles. 
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On distingue dans cette adresse plusieurs parties : 

• Le mot-cle sip specifle le protocole a utiliser pour la communication. Par analogie avec 
le Web (ou une page est referencee par une adresse de type http.V/monsite), le mot-cle 
sip precise que ce qui va suivre est 1' adresse d'un utilisateur. 

• La partie identifiant deflnit le nom ou le numero de 1' utilisateur. Cet identifiant est 
necessairement unique pour designer l'utilisateur de maniere non ambigue. 

• La partie mot_ dejpasse est facultative. Le mot de passe peut etre utile pour s'authen- 
tifler aupres du serveur, notamment a des fins de facturation. C'est aussi un moyen 
pour joindre un utilisateur qui a souhaite s'enregistrer sur l'equivalent d'une liste 
rouge : sans la connaissance de ce mot de passe, le correspondant n'est pas joignable. 
De maniere generale, cette possibilite offre le moyen de restreindre 1' utilisation de 
certains services. 

• La partie serveur specifle le serveur charge du compte SIP dont 1' identifiant precede 
l'arobase. Le serveur est indique par son adresse IP ou par un nom qui sera resolu par 
DNS. Des parametres URI peuvent etre associes a ce nom. C'est ce serveur qui sera 
contacte pour joindre l'abonne correspondant. Un port peut etre specifle a la suite du 
serveur. 

• La partie parametres est facultative. Les parametres permettent soit de modifier le 
comportement par defaut (par exemple, en modifiant les protocoles de transport ou les 
ports, ou encore le TTL par defaut), soit de specifier des informations complementaires 
(par exemple, l'objet d'un appel qui sera envoye a l'appele en meme temps que l'indi- 
cation d'appel, a la maniere d'un e-mail precisant l'objet du message). 

Le tableau 4.1 fournit quelques exemples d'adresses SIP commentees. 



Tableau 4.1 - Exemples d'adresses SIP 



Adresse SIP 



<sip:guy.laurent@123. 123. 123. 123> 



<sip:+33145555555:mon_pass 123@ma_passerelle_rtc> 



Commentaire 



C'est le format le plus commun. L'identifiant de l'utilisateur est 
specifie par un nom ou un pseudonyme, guy.laurent. Apres 
l'arobase est specifiee I'adresse IP du serveur en charge de la 
gestion du compte de guy.laurent. Cette adresse IP etant fixe, 
il n'est pas necessaire de la resoudre par un DNS, et il est pos- 
sible de contacter directement ce serveur. L'lP fixe n'est gene- 
ralement pas pratique, car une adresse fixe oblige le 
fournisseur d'acces a conserver ses mecanismes d'adressage 
ou a avertir ses utilisateurs de toute modification. 

Le premier nombre (+33145555555) est le numero de tele- 
phone du correspondant. On peut supposer qu'il s'agit d'un 
numero geographique et que le correspondant est actif dans le 
reseau RTC. Pour joindre ce reseau, il faut passer par une pas- 
serelle, donnee juste apres l'arobase, dont le nom est 
ma_passerelle_rtc. L'utilisation d'un mot de passe 
(mon_pass1 23) permet a I'appelant de s'authentifier aupres du 
serveur ma_passerelle_rtc pour avoir le droit d'emettre I'appel 
(notamment pour la facturation). 
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Tableau 4.1 - Exemples d'adresses SIP (suite) 

Adresse SIP Commentaire 

<sip:guy.laurent@sip_ietf.org:12345?sub- Cette adresse est semblable a la premiere, mais avec des 

ject=Confirmation_RendezVous;transport=tcp:54321> parametres supplemental. Elle comporte un nom d'utilisa- 

teur (toujours guy.laurenf) et un serveur a contacter pour etre 
mis en contact avec I'utilisateur. Le serveur etant nomme 
sip_ietf.org, son nom devra etre resolu par un DNS afin de 
determiner son adresse IP. II sera contacte sur le port 12345. 
Cette adresse fournit les informations complementaires sui- 
vantes : 

- Un sujet, qui indique le motif de I'appel : 
Confirmation_RendezVous. En meme temps que le terminal 
appele sonnera, le nom de I'appelant et le sujet de son appel 
pourront etre affiches sur le terminal, sous reserve que ce der- 
nier supporte ce service. 

- Un protocole de transport impose : tcp. Par defaut, c'est le 
protocole UDP qui est utilise dans les communications. 

- Un port a utiliser pour la communication : 54321. Par defaut, 
c'est le port 5060 qui est utilise. 

On retiendra deux avantages de l'adressage SIP : 

• L'adressage est independant de la localisation geographique des abonnes. SIP est 
con^u pour assurer la mobilite de ses utilisateurs, et done permettre de joindre 
quelqu'un avec une adresse SIP unique, quels que soient sa localisation et son 
terminal. Le reseau peut toutefois adopter un plan de numerotation selon n'importe 
quel critere, comme la localisation geographique, sans que cela soit genant. 

• Un utilisateur peut avoir plusieurs adresses SIP aboutissant toutes au meme terminal. 
Par exemple, si quelqu'un souhaite differencier son adresse SIP professionnelle de son 
adresse SIP personnelle, il peut utiliser un meme terminal reference sur deux adresses 
distinctes. II lui est alors possible d'activer la messagerie de son compte personnel 
pendant son travail et, le week-end, de rediriger les appels sur son adresse profession- 
nelle vers un centre de permanence. Le tout en utilisant un terminal unique. 

Ce mecanisme d'adressage particulierement souple permet de supporter la mobilite des 
utilisateurs et le monde Internet. 



Localisation et resolution d'une adresse SIP 

D'une maniere generale, une adresse SIP specifie un utilisateur et un nom de domaine. 
Pour localiser I'utilisateur, il faut d'abord contacter le serveur gerant le domaine puis 
sollicker ce serveur pour determiner la position de I'utilisateur. 

Si la partie indiquant le serveur de domaine contient une adresse IP, ce serveur est joint 
directement. A defaut, 1' adresse IP du serveur sera determinee apres une resolution DNS. 
La demande de localisation de I'utilisateur s'effectue aupres du serveur de domaine ainsi 
contacte. La position de I'utilisateur peut etre referencee de maniere absolue ou relative. 
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Le cas simple consiste en une position absolue, specifiant une adresse IP localisant 
l'utilisateur. Le cas plus complexe consiste en une position relative, specifiant une 
autre adresse SIP. Dans ce cas, il faut repeter 1' operation de resolution de cette 
nouvelle adresse SIP depuis le debut : contacter le serveur SIP gerant le domaine puis 
lui demander la position de l'utilisateur. 

Dans le cas illustre a la figure 4.6, il s'agit de localiser l'utilisateur david a partir de son 
adresse SIP david.dad@dom_A.fr. Cet utilisateur possede une autre adresse SIP, qui est 
dav@dom_B.fr. L'une correspond a une adresse professionnelle, 1' autre a une adresse 
personnelle. Naturellement, l'utilisateur souhaite rester joignable sur ces deux adresses 
simultanement. 



Serveur DNS 




dom A.fr 



dom_B.fr 



1. Ou se trouve dom_A.fr ? 



2. IP de dom_A.fr : 1.2.3.4 



5. Ou se trouve dom_B.fr ? 



6. IPdedom_B.fr : 4.3.2.1 



Nom du domaine Adresse IP 



■*• 1.2.3.4 



■*• 4.3.2.1 



Ou se trouve David 

dont I'adresse SIP 

est 

david.dad@dom_A.fr ? 



Caroline 



Appelant 



3. Ou se trouve david.dad ? 



4. david.dad se trouve a 
dav@dom_B.fr 



Serveur SI P ' 
Nom : dom_A.fr 
IP : 1.2.3.4 




david.dad -> dav@dom_B.fr 

— ^ 



Z~ 



7. Ou se trouve dav ? 



8. dav se trouve a 
1.234.56.78 



' Serveur SI P ' 

Nom : dom_B.fr 

IP : 4.3.2.1 




dav * 1.234.56.78 



IT" 



9. David est localise! 



A 



David 



Appele 

david.dad@dom_A.fr 

IP : 1.234.56.78 



Figure 4.6 

Principe de localisation a partir d'une adresse SIP 



Pour que l'exemple soit valide, il faut considerer que, prealablement a la localisation, 
l'utilisateur david s'est enregistre aupres du serveur SIP gerant le domaine dom_A.fr 
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en lui fournissant 
( da v @ dom_B.fr). 



son identifiant (david.dad) et une adresse SIP associee 



Notons que le serveur indique dans la partie domaine d'une adresse SIP peut etre un 
serveur SIP de type proxy ou une passerelle permettant de joindre des utilisateurs d'un 
reseau non-IP. 



Les messages SIP 

Les messages SIP sont decrits dans la RFC 822, qui definit la syntaxe a la fois des reque- 
tes et des reponses. On y trouve une tres forte influence des autres protocoles de 1'IETF, 
principalement HTTP et SMTP. Le format des requetes et reponses est en effet similaire 
a celui utilise dans le protocole HTTP, et les en-tetes s'apparentent a celles utilisees dans 
le protocole SMTP. On y retrouve par ailleurs le concept d'URL. 

Les sections qui suivent detaillent le « langage SIP », afin de montrer comment s'effec- 
tuent les communications entre les interlocuteurs. L'objectif est d'apprendre a la fois a 
decrypter les echanges entre les intervenants et a ecrire une application SIP. 



Notion de transaction 

Une communication est constitute d'une succession de transactions par le biais d' echan- 
ges de messages, qui peuvent etre soit des requetes, soit des reponses a des requetes. 

Une transaction SIP peut s' entendre en premiere approximation selon le sens commun : 
un emetteur formule une demande a un recepteur. Ce dernier etudie les conditions de la 
demande avant de repondre. Eventuellement, il peut etre amene a envoyer des reponses 
temporaires, indiquant revolution du traitement de la requete. 

Une transaction est done constitute d'une requete et de sa ou ses reponses. Pour se mettre 
d' accord sur la nature de l'echange, chaque intervenant est susceptible de negocier les 
parametres de la session au moyen de nouvelles transactions. 

Les messages SIP sont codes en utilisant la syntaxe de message HTTP/1.1 (RFC 2068). 
Qu'il soit une requete ou une reponse a une requete, un message SIP doit respecter le 
format illustre a la figure 4.7. 



Figure 4.7 

Format generique d'un message 
SIP 
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Lignede requete ou d'etat 
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En-tete 
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Corps du message 
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La premiere partie est soit une ligne de requete, s'il s'agit d'une requete, soit une ligne 
d'etat, s'il s'agit d'une reponse. La seconde partie rassemble les en-tetes du message. 
Enfin, vient le corps du message. Optionnel, celui-ci est precede d'une balise de retour 
chariot et saut de ligne CR-LF (Carriage Return-Line Feed) afln d'indiquer le debut du 
corps du message. Cette balise assure la separation de l'en-tete et du corps du message, 
ce qui permet d'optimiser le temps de traitement des messages. 

La separation des champs reduit le temps de transit des messages dans le reseau. De cette 
maniere, les serveurs intermediaries peuvent rapidement discerner les informations 
utiles, sans avoir a manipuler les donnees du corps du message. 

La specification du protocole limite le nombre d' en-tetes possible, ce qui permet de borner le 
temps de lecture ou d'ecriture des messages. En theorie, 36 en-tetes peuvent etre utilises au 
maximum. Dans la pratique, guere plus d'une dizaine est utilisee simultanement. 

Parametres generaux pour les requites et les reponses 

Certains parametres generaux peuvent etre partages a la fois par les messages de requete 
et par les messages de reponse. 

Les sections suivantes detaillent les caracteristiques specifiques a la constitution des 
requetes puis a celles des reponses. 

En-tetes d'un message 

Un message de requete comme un message de reponse peut contenir des en-tetes. 
Les en-tetes les plus couramment utilises dans les messages SIP sont les suivants : 

• En-tetes generaux, qui peuvent etre utilises indifferemment pour des messages de 
requete ou des messages de reponse. 

• En-tetes de requete, exclusivement employes pour les messages de requete. 

• En-tetes de reponse, exclusivement employes pour les messages de reponse. 

• En-tetes d'entite, qui donnent des informations descriptives sur le corps du message. 

Le tableau 4.2 recapitule les principaux champs d' en-tetes, classes selon ces quatre cate- 
gories. Toutes les methodes SIP ne supportent pas forcement tous ces champs. 

Tableau 4.2 - Principaux champs d'en-tetes des messages SIP 

Champ d'en-tete Commentaire 

En-tetes generaux 

accept Ce champ est utilise dans les messages invite, options et register afin de specifier le format qui devra 

etre supporte en reponse. Par exemple, accept: application/sdp signifie que le corps de la reponse a ce 
message devra etre de I'applicatif code avec le langage SDP (valeur par defaut de ce champ). 



accept-encoding Specifie le type d'encodage textuel accepte dans le corps du message de la reponse du client. Par 

exemple, Accept-Encoding:gzip signifie que le recepteur pourra utiliser le format gzip pour compresser 
le corps de son message. 
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Tableau 4.2 - Principaux champs d'en-tetes des messages SIP (suite) 



Champ d'en-tete 

ACCEPT-LANGUAGE 

CALL-ID 

CSEQ 

FROM 



TO 



VIA 



EXPIRES 

En-tetes de requete 

SUBJECT 
PRIORITY 



USER-AGENT 



En-tetes de reponse 

RETRY-AFTER 



SERVER 



Commentaire 

Specifie le langage accepte dans le corps du message de la reponse du client. Par exemple, Accept- 
Language:fr signifie que le corps du message de reponse pourra etre exprime en frangais. 

Indique le numero d'identification d'un appel (voir plus loin). Par exemple, Call-id:1 3d11a45d@ietf.org 
identifie une session. 

Indique le numero d'une commande unique (voir plus loin). Par exemple, CSeq:1 51 97903 INVITE iden- 
tifie la commande invite avec un numero de commande associe de valeur 15197903. 

Indique I'adresse SIP de I'emetteur du message. Par exemple, From:Nathalie<sip:natha- 
lie@domaine_ietf.org> identifie I'appelant Nathalie avec I'adresse fournie. 

Indique I'adresse SIP du recepteur du message. Par exemple, To:Henri<sip:henri@domaine_ietf.org> 
identifie I'appele Henri avec I'adresse fournie. 

Liste I'ensemble des noeuds parcourus par le message (voir plus loin). Par exemple : 

VIA:SIP/2.0/UDP 142. 132.227. 1 11:5060 

VIA:SIP/2.0/UDP proxy-lambda:5060 

VIA:SIP/2.0/UDP emetteur:5060 

permet de savoir que le message est passe par I'emetteur avant de traverser le noeud dont le nom est 

proxy-lambda puis le noeud dont I'adresse est 142. 132.227. 1 1 1. 

Specifie la date et I'heure d'envoi du message. Cette donnee est exprimee au format GMT (Greenwich 
Mean Time) et est sensible a la casse. Par exemple, Date:Thu, 15 Mar 2012 11:35:10 GMT definit la 
date du jeudi 15 mars 2012, a 11 heures 35 minutes et 10 secondes, heure GMT. 

Specifie la duree au bout de laquelle le message peut etre efface. Cette duree est indiquee en seconde. 
Par exemple, Expires:3 definit une duree de 3 secondes avant que le message soit detruit. 



Indique I'objet de I'appel. Par exemple, subjectanniversaire surprise de David demain /definit un sujet 
indiquant le message specifie a I'appelant lorsque son telephone sonne. 

Indique la priorite d'une session, c'est-a-dire importance qui devrait etre accordee a I'appel sollicite. 
On denombre quatre priorites par ordre decroissant d'importance : emergency, urgent, normal, non- 
urgent. La priorite emergency est reservee a une situation de danger vitale et ne devrait pas etre 
exploitee pour des messages d'une autre nature. Par exemple, priority=urgent caracterise un message 
d'importance classee urgente. 

Fournit des informations sur le logiciel utilise par le terminal UAC. Cette information peut cependant 
etre une source de vulnerability si elle est divulguee a des personnes mal attentionnees. Les logiciels 
off rent generalement la possibility de masquer cette information. Par exemple, Server :Lite Sip Commu- 
nicator 1. 6 signifie que I'UAC utilise le logiciel Lite Sip Communicator 1.6 pour appeler. 



Est utilise conjointement avec une reponse d'indisponibilite d'un correspondant pour specifier le temps 
(exprime en seconde) au bout duquel il convient de renouveler I'appel. Si aucune valeur n'est donnee, 
le serveur contacte est considere comme indisponible pendant une duree indeterminee. Par exemple, 
Retry- After :300 signifie qu'il faut rappeler 5 minutes apres I'heure ou le message a ete envoye. On peut 
egalement fournir un motif explicatif textuel a I'indisponibilite du contact, par exemple : Retry-after :3600 
(je suis alle dejeuner). 

Fournit des informations sur le logiciel utilise par le terminal UAS. De meme que pour I'en-tete user- 
agent, il s'agit d'une donnee potentiellement sensible. Par exemple, Server:Sip Phone 1.5.2 signifie 
que le terminal UAS utilise le logiciel Sip Phone 1 .5.2 pour repondre a I'appel. 
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Tableau 4.2 - Principaux champs d'en-tetes des messages SIP (suite) 

Champ d'en-tete Commentaire 

En-tetes d'entite 

content-type Indique le format utilise dans le corps et le langage qui le decrit. Par exemple, content-type :text/htm I 

signifie que le corps du message contient du texte code en langage HTML. De meme, content- 
type:application/sdp indique que le corps du message contient de I'applicatif code en langage SDP. 

content-length Indique la taille du corps du message exprimee en octets. Par exemple, Content-Lenght:155 signifie 

que le corps du message fait 155 octets. 

content-encoding Indique le format de compression utilise dans le corps du message. La compression est optionnelle. 

Par exemple, Content-Encoding:gzip signifie que le corps du message est compresse selon le format 

gzip- 

content-language Indique la langue utilisee dans le corps du message. Par exemple, Content-Language:fr signifie que le 

corps du message est en frangais. 

Le champ VIA pour detecter les boucles lors du routage 

Le champ d'en-tete VIA permet d'indiquer le chemin parcouru par un message entre un 
emetteur et son recepteur. 

Ce chemin designe 1' ensemble des noeuds intermediaries par lesquels transite le message. 
Chaque nceud qui re^oit le message enrichit ce champ en y ajoutant son adresse reseau. 
Plus precisement, un nouveau champ VIA est ajoute pour chaque noeud traverse, conte- 
nant le type de protocole de transport utilise, 1' adresse IP (ou le nom a resoudre par DNS) 
du noeud et eventuellement le port sur lequel tourne 1' application SIP. Le protocole de 
transport peut etre choisi parmi UDP, TCP, TLS ou SCTP. 

Un exemple de champ via peut etre (les espaces sont tolerees) : 

Via:SIP / 2.0 / TCP nceud_de_transit: 34567 

Toutes les entites qui regoivent ce message et sont chargees de le faire suivre jusqu'a son 
destinataire doivent ajouter une ligne similaire. 

Grace a ce champ via, les boucles peuvent facilement etre detectees par les serveurs 
proxy traverses. Dans ce cas, en effet, le serveur qui marque la traversee du message en 
ajoutant un nouveau champ via trouve sa propre adresse dans un autre champ via. II en 
deduit que le routage comporte une boucle et en avertit 1' emetteur ou tente une autre 
route. 

Une autre caracteristique de ce champ est de permettre au recepteur de retracer le chemin 
inverse lors de sa reponse, de maniere que son message suive la meme route. En effet, la 
reponse contient les memes champs VIA que la requete. Chaque serveur proxy qui re^oit 
le message de reponse retire sa propre adresse du champ via du message, puis envoie le 
message a 1' adresse suivante. De proche en proche, la reponse suit la meme route que la 
requete, et il n'est pas necessaire de recourir a des serveurs DNS ou de gerer des etats des 
liens de chaque connexion dans les serveurs proxy. 
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Difference entre Call-Id et CSeq 

Le Call-Id, ou identifiant d'appel, est un numero identifiant une session particuliere. Tous 
les messages lies a une meme session portent obligatoirement un meme identifiant 
d'appel. De cette maniere, on peut decrire une session par son Call-Id associe. 

Tous les utilisateurs d'une meme session exploitent done le meme Call-Id, y compris lors 
d'une conference. Cela vaut aussi pour les serveurs intervenant dans la signalisation des 
messages SIP, ces derniers distinguant les sessions auxquelles un message fait reference 
par leur identifiant d'appel. 

Le Call-Id est genere lors de 1' initialisation de l'appel par le terminal client. Par exemple, 
un Call-Id peut etre : Call-Id: al -b2-c3-45@ietf.org. Cet identifiant est reporte dans tous 
les messages SIP lies a la session, et ce quel que soit leur emetteur. 




Serveur proxy 





Requete .- 
Cat-ID -23553@ietf. ra 

_ Cseq = 1 



Reponse : 



Heponse . 

= 23553@ietf.org 

Cseq- A 
Requete : 



Call-ID 

i = 1 




Requete : 
Call-ID = 23553@ietf.org 
__Cseq=i y 



Premiere 
session 



Seconde 
session 



Figure 4.8 

Differences entre Call-Id et CSeq 



Une communication peut toutefois etre repartie entre plusieurs sessions. Par exemple, 
une conference peut mettre en place une session audio et une session video distinctes. 
Dans ce cas, chacune des sessions dispose d'un identifiant d'appel different. 
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Le CSeq (Command Sequence), ou ordre de commande, est constitue de 1' association 
d'un numero et de la requete correspondante. II permet de differencier chaque message 
de requete. Lorsqu'un terminal en emet plusieurs au cours d'une meme session, il distin- 
gue a quelle requete fait reference une reponse grace a 1' ordre de commande CSeq. Deux 
CSeq ne sont egaux que s'ils ont simultanement le meme numero et la meme requete. 

Un exemple de CSeq pourrait etre : CSeq:l INVITE pour le premier message d'initialisa- 
tion d'une session (methode invite). Ensuite, ce numero est repris identiquement pour 
les messages qui relaient la requete et pour les messages qui fournissent une reponse. A 
la prochaine requete, 1' ordre de commande est increments d'une unite (passant done a 2), 
et ainsi de suite. 

La figure 4.8 illustre la difference entre Call-Id et CSeq. Dans cet exemple, Bastien initie 
une communication avec Caroline (en passant par un serveur proxy). Au depart, le Call- 
Id est arbitrairement fixe a 23553@ietf.org et le CSeq debute a 1. Le CSeq ne sera incre- 
mente qu'avec une nouvelle requete. Quant au Call-Id, il ne changera que plus tard lors- 
que Bastien lancera une autre session vers Alex (en liaison directe). Par souci de simpli- 
fication, les messages de signalisation et la communication multimedia entre les 
correspondants n'ont pas ete representes. 

Abreviation des en-tetes de messages 

Les en-tetes SIP sont indiques juste apres la ligne de requete ou d'etat. Aucun ordre n'est 
impose. Les en-tetes se succedent, simplement separes par des points- virgules. 

Chaque parametre d'en-tete est precede du champ qui lui correspond, en respectant la 
syntaxe generique suivante (les espaces sont tolerees) : 

entetehvaleurl; entete2:valeur2; entete3:valeur3; ... 

Par exemple, pour specifier que le Call-Id d'un message a pour valeur 170451@ietf.org, 
on ecrit : call-id: 17045 l@ietf.org, et ainsi de suite pour chaque parametre, independam- 
ment de leur ordre d' apparition. 

Cette succession de parametres alourdit cependant la taille du message, qui peut rapide- 
ment devenir tres importante. Cela pose d'autant plus probleme si les paquets doivent 
respecter une taille limitee par une MTU (Maximum Transmission Unit). La MTU 
impose en effet une valeur au-dela de laquelle le paquet doit etre segmente. 

Pour eviter cette segmentation et reduire globalement la taille des envois, le protocole 
SIP permet d'utiliser des abreviations, dites formes compactes, pour representer les en- 
tetes les plus courants. 

Une forme compacte s' ecrit en une lettre seulement. Pour la meme information de Call- 
Id que precedemment, on peut ecrire : i: 17045 l@ietf.org, la lettre / se substituant a call- 
id. Notons toutefois que tous les en-tetes ne disposent pas d'une forme compacte, qui 
reste 1' apanage des plus usuels d' entre eux. 
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Le tableau 4.3 recapitule quelques-unes de ces abreviations. II est possible de melanger 
dans un meme message les formats longs avec les formats compacts des en-tetes. Toutes 
les entites SIP doivent savoir interpreter les deux formes. 

Tableau 4.3 - Abreviations de certains champs d'en-tetes 



Format complet 


Format compact 


Call-Id i 


FROM 


f 


TO 


t 


VIA 


V 


SUBJECT 


s 


CONTENT-TYPE 


c 


CONTENT-LENGTH 1 


CONTENT-ENCODING 


e 



Corps d'un message 

Le corps d'un message SIP contient le descriptif complet des parametres de la session 
concernee. 

Typiquement, une description de la session a ouvrir comporte les informations suivantes : 

• informations generates sur la session (nom de la session, date de la session, objet de la 
session, etc.) ; 

• informations sur l'emetteur du message (nom, e-mail, numero de telephone, etc.) ; 

• informations reseau (ressources necessaires, protocole et port utilises pour le transport 
des donnees multimedias, etc.) ; 

• liste des flux multimedias utilises (audio, video, texte) ; 

• liste des codages supportes (G.71 1, G.729, H.216, MPEG, etc.) ; 

• informations de securite (type de cryptage utilise). 

Ces informations sont fournies soit pour etre negociees avec le correspondant, soit pour 
etre fixees au terme de la negotiation. Elles permettent de s'accorder prealablement a 
l'echange sur la compatibilite des terminaux. 

C'est l'en-tete qui precise dans quel langage sont specifiees les informations donnees 
dans le corps du message (avec le champ content-type). Le plus couramment, ces 
specifications s'effectuent soit sous forme textuelle, en utilisant le langage HTML, soit 
sous forme applicative, en utilisant le langage protocolaire SDP. 
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SDP (Session Description Protocol) 

Decrit dans la RFC 2327, le protocole SDP a ete con^u par 1'IETF dans le cadre de 
MMUSIC, le groupe de travail a l'origine du protocole SIP. 

Son role est de decrire 1' ensemble des parametres constituant une session. Cela inclut la 
specification des medias utilises, des protocoles de transport, des ports, des codages, des 
ressources necessaires et des dates d'activite de la session. 

Avec SDP, la syntaxe des specifications du corps respecte le modele suivant : 

parametre = valeur 

Les parametres peuvent appartenir a deux categories distinctes : 

• Globale : le parametre s'applique a l'ensemble de la session (parametre de media). 

• Locale : le parametre ne s'applique qu'a un media particulier (parametre de media). 

Certains champs de parametres sont propres a Tune ou 1' autre de ces categories, tandis 
que d'autres peuvent etre employes indifferemment dans les deux categories. Seul 
l'ordre d' apparition permet de distinguer le champ d' application des parametres. 

Chaque parametre est caracterise par une lettre. 

Le tableau 4.4 recapitule quelques-uns des champs possibles deflnis avec SDP. 

Tableau 4.4 - Champs SDP les plus courants 



Champ 
SDP 


Correspondance 


Type d'information 


Descriptif 


Presence du champ 


V 


PROTOCOL VERSION 


Description de session 


Version du protocole 


Requise 





OWNER / CREATOR AND 
SESSION IDENTIFIER 


Description de session 


Norn du createur de la session 
et identification de la session 


Requise 


s 


SESSION NAME 


Description de session 


Norn de la session 


Requise 


i 


MEDIA TITLE 


Description de session 
et de media 


Information sur la session 


Optionnelle 


u 


URI 


Description de session 


URI de description de la 
session 


Optionnelle 


e 


EMAIL ADDRESS 


Description de session 


E-mail du createur de la session 


Optionnelle 


P 


PHONE NUMBER 


Description de session 


Numero de telephone du 
createur de la session 


Optionnelle 


c 


CONNECTION 
INFORMATION 


Description de session 
et de media 


Adresse reseau avec laquelle 
s'effectue la connexion. 


Requise soit dans la 
description de la 
session, soit dans 
toutes les descriptions 
de media 


b 


BANDWIDTH INFORMATION 


Description de session 
et de media 


Debit necessaire 


Optionnelle 


t 


TIME 


Description temporelle 


Date d'activite de la session 


Requise 

l 
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Tableau 4.4 - Champs SDP les plus courants (suite) 




Champ 
SDP 


Correspondance 


Type conformation 


Descriptif 


Presence du champ 


r 


REPEAT TIMES 


Description temporelle 


Repetition de la session. Cette 
duree commence a partir de la 
valeur de debut de session 
indiquee dans le champ t. 


Optionnelle 


z 


TIME ZONE ADJUSTMENTS 


Description de session 


Information horaire 


Optionnelle 


k 


ENCRYPTION KEY 


Description de session 
et de media 


Cle de cryptage utilisee 


Optionnelle 


a 


SESSION ATTRIBUTE 


Description de session 
et de media 


Attributs de media 


Optionnelle 


m 


MEDIA NAME AND 
TRANSPORT ADDRESS 


Description de media 


Type de media utilise et adresse 
de transport 


Requise 



Les parametres doivent imperativement respecter l'ordre donne dans le tableau. On 
trouve d'abord les parametres generaux (caracterisant la session), puis les parametres 
particuliers (qui s'appliquent seulement a un media, lequel est deflni par le champ m). 

Les parametres particuliers decrivant un media sont mentionnes apres le champ m. Tout 
parametre indique avant le champ m sera considere comme decrivant une session tout 
entiere. Autrement dit, les champs SDP qui peuvent decrire a la fois une session et un 
media sont interpretes selon leur emplacement dans le corps du message. Avant le champ 
m, ils s'appliquent a une session. A la suite du champ m, ils ne s'appliquent qu'au media 
decrit par le champ m. A la suite de ce champ m, on peut done reprendre les parametres 
du tableau ay ant pour type la description d'une session et qui s'appliqueront cette fois 
pour decrire uniquement le media mentionne par le champ m. 

Un exemple de corps de message SDP peut etre : 



v=0 

o=lenzo 2890844526 2890842807 IN IP4 132.227.60.4 

s=Message test 

i=Ce message permet d 'analyser quelques champs SDP courants 

u=http:/ /www. monsitesurlavoip.com/ docs/ protocol e_sdp.doc 

e=Laurent. guy@monsitesurlavoip.com (Laurent Guy) 

p=+33-061-770-5555 

c=IN IP4 132.227.60.12/125 

t= 2873397496 2873404696 

a=sendrecv 

m=audio 49170 RTP/AVP 

m=video 51372 RTP/AVP 31 32 

m=appli cation 32416 udp wb 

a=orient:portrait 
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Le tableau 4.5 reprend cet exemple de message SDP en le commentant. 
Tableau 4.5 - Exemple de message SIP complet commente 



Ligne de message 

v=0 



o=lenzo 2890844526 2890842807 IN 
IP4 132.227.60.4 



s=Message test 

i=Ce message permet d'analyser 
quelques champs SDP courants 

u=http://www. monsitesurlavoip. com/docs/ 
protocole_sdp.doc 

e= Laurent. guy@monsitesurlavoip. com 
(Laurent Guy) 

p=+33-061 -770-5555 

C=IN IP4 132.227.60.12/125 



Commentaire 

Indique que c'est la version du protocole SDP qui est utilisee dans ce message. 

Cette ligne respecte le format <nom d'utilisateur> <identifiant de session> <version 
de l'annonce> <type de reseau> <format de I'adresse reseauxadresse reseau>, 
avec les caracteristiques suivantes : 

- Le nom d'utilisateur indique I'identifiant de la personne a I'origine du message. Le 
tiret (caractere -) peut etre utilise pour ne pas preciser d'identifiant. 

- Lidentifiant de session est une chaine de caracteres numeriques definie de 
maniere que, hormis le parametre de version, les cinq autres elements constituant 
le champ o (c'est-a-dire nom d'utilisateur, identifiant de session, type de reseau, for- 
mat de I'adresse reseau et adresse reseau) forment une identification unique. Un 
utilisateur devra modifier la valeur de ce parametre lors d'une nouvelle session, tan- 
dis qu'un autre utilisateur pourra utiliser le meme identifiant de session. Generale- 
ment, mais pas obligatoirement, la valeur de ce champ est donnee par le protocole 
NTP, qui fournit I'heure suivant differents formats, ici en seconde. 

- La version de I'annonce est attribute afin de determiner I'anteriorite des messa- 
ges. Ainsi, si une entite regoit plusieurs messages d'annonce affectes a une meme 
session, elle considerera le plus recent d'entre eux, c'est-a-dire celui qui possede le 
numero de version le plus grand. La encore, il est recommande, sans que ce soit 
obligatoire, d'utiliser le protocole NTP pour donner une valeur a ce champ. 

- Le format de I'adresse qui va suivre est specifie par IP4, qui indique que c'est la 
version 4 du protocole IP qui est utilisee (le code IP6 renvoie a IPv6). 

- Le type de reseau utilise est generalement Internet, qui est mentionne par le code 
IN. 

- L'adresse IP qui suit est celle du terminal a I'origine de I'annonce. 

Specifie le nom donne a la session. 
Message informatif decrivant la session 

L'URI indique un pointeur sur lequel des informations concernant la session cou- 
rante peuvent etre trouvees. 

L'e-mail de la personne a I'origine du message peut etre mentionne indifferemment 
sous la forme e=mail (nom_de_la_personne) ou e=nom_de_la_personne <email> 
ou encore simplement e=mail. 

Le numero de telephone doit etre indique selon le format international. Les tirets 
peuvent etre remplaces par des espaces. 

Le champ de connexion possede le format <type de reseau> <format de I'adresse 
reseau> <adresse reseau de connexion>/<ttl>/<nombre d 'adresse de diffusion>. 
Mors que le type de reseau et le format de I'adresse reseau sont semblables a ce qui 
a ete indique precedemment pour le champ o, I'adresse reseau de connexion spe- 
cifie I'adresse reseau (ou le nom a resoudre par DNS) de I'entite avec laquelle la 
connexion va s'effectuer. 

Avec ce champ c, il est possible d'indiquer autant de lignes que de destinataires du 
flux mentionne. 

La duree de vie des messages envoyes, ou TTL (Time to Live), en seconde est indi- 
quee a la suite et prend une valeur comprise entre et 255. 
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Tableau 4.5 - Exemple de message SIP complet commente (suite) 



c=IN IP4 132.227.60.12/125 (suite) 



t=2873397496 2873404696 



a=sendrecv 



m=audio 49170 RTP/AVP 
m=video 51327 RTP/AVP 31 32 
m=application32416UDP wb 
a=orient:portrait 



Si ce champ se trouve avant la description des medias (champ m), il s'applique aux 

medias sans distinction (tous les correspondants auront les memes types de fl ux). 

S'il suit une description de media, il est limite aii media correspondant (par exemple, 

pour mettre en place une conference avec une communication audio et video avec 

un correspondant et une communication audio seulement avec un autre). 

Dans le cas ou plusieurs terminaux sont concernes par le flux, il est necessaire de 

repeter cette ligne pour chacun des destinataires. Une autre maniere de faire, si 

I'adressage s'y prete, consiste a utiliser un adressage multicast en mentionnant la 

base reseau de multicast et le nombre de terminaux concernes. 

Ainsi, la ligne suivante : 

c=IN IP4 132.227.60.1/125/3 

est equivalente aux lignes : 

C=IN IP4 132.227.60.1/125 

C=IN IP4 132.227.60.2/123 

c=IN IP4 132.227.60.3/125 

Par defaut, le nombre d'adresses de diffusion est 1 , et cette valeur peut etre omise. 

Une conference peut etre bor nee dans le temps par I'attribution d'une valeur temporelle 
de debut et de fin dans le champ t. Celui-ci donne respectivement un horaire auquel 
debute la conference et un autre auquel elle s'acheve (defini au format decimal de NTP, 
en seconde). La valeur comme horaire de fin n'indique pas de fin pour I'appel. De 
meme, la valeur comme horaire de debut indique une session permanente. 

II existe de nombreuses possibilites d'attributs. Leur format doit respecter I'une des 
deux syntaxes suivantes : 

-a=< nom_attribut >. permet de positionner un attribut binaire. Par exemple, 
a=sendrecv indique que les flux multimedias peuvent etre inities en reception 
comme en emission (send receive). 

- a=< nom_attribut >:<valeur> prmet de donner une valeur a un attribut. Par exem- 
ple, si Ton partage un tableau blanc, pour indiquer qu'on souhaite I'orienter en mode 
portrait, on indique a=orient:landscape. De meme, si Ton souhaite indiquer le nom 
du programme ayant permis de constituer le message SDP, on utilise 
a=tool:monprogrammesdp 1.3. 

Le format est mentionne selon la syntaxe suivante : 
<media> <port>/<nombre de port> <transport> <format> 
Le type de media est defini d'abord. II peut avoir les valeurs predefines suivantes : 
'audio', 'video', 'application', 'data'el 'control'. Eventuellement, des valeurs supple- 
mental peuvent etre proposees. 

Le port concerne par la diffusion de ce type de media est indique a la suite. Dans le 
cas ou les numeros de ports se suivent, il est possible de mentionner le nombre de 
ports concernes. Par exemple, en mentionnant comme port 1234/2, les ports 1234 
et 1235 seront utilises pour ce flux. Par defaut, c'est la valeur non obligatoire 1 qui 
definit le nombre de port. 

Le transport mentionne le nom du protocole de transport utilise. On distingue les 
deux valeurs suivantes : 

- RTP/AVP /transport avec le protocole RTP en utilisant les parametres audio-video 
(Audio/Video profile). Implicitement, c'est le protocole UDP qui est utilise pour les 
flux RTP. 

- UDP :seul le protocole UDP est utilise. 
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Tableau 4.5 - Exemple de message SIP complet commente (suite) 

(suite) II est possible d'etendre ces valeurs. 

m=audio 49170 RTP/AVP Le format est indique a la suite. II correspond a un type definissant le codage des 

m=video 51327 RTP/AVP 31 32 donnees. Par exemple, la valeur correspond a un codage de type G.71 1 loi mu, uti- 

m=application 32416 UDP wb '' sant un seu ' cana ' auc '' avec une frequence de 8 kHz. De meme, avec un seul 

a=orienfportrait cana ' et une Sequence de 8 kHz, la valeur 8 est utilisee pour un codage G.71 1 loi A, 

la valeur 2 pour un codage G.721 , la valeur 3 pour un codage GSM et la valeur 9 
pour un codage G.722. La RFC 1890 liste les differentes valeurs de codage possi- 
bles. 

Plusieurs formats de codage peuvent etre indiques dans cette liste pour indiquer 
que tous ces formats sont susceptibles d'etre utilises au cours de la session, bien 
que, par defaut, ce soit le premier mentionne dans la liste qui est utilise (c'est le cas 
pour le media video, pour lequel deux formats sont donnes, 31 pour un codage 
H.261 et 32 pour un codage MPV). De plus, certaines valeurs peuvent etre rempla- 
cees par des parametres. Par exemple, le parametre wb (pour whitepaper) definit le 
format du tableau blanc. 

Dans I'exemple, trois medias differents sont definis (audio, video et application). Le 
champ a etant mentionne apres le champ m est un champ de media qui s'applique 
uniquement au dernier media mentionne (en I'occurrence le media application). 

Le protocole SDP fournit un langage descriptif des sessions relativement simple, mais 
limite, puisqu'il n'offre pas de logique permettant d'exprimer des solutions de configura- 
tion differentes. En outre, il n'est pas extensible, ce qui interdit d'ajouter de nouveaux 
parametres descriptif s. 

D'une maniere generate, le corps d'un message est rempli (ou non) selon le type du 
message. En ce qui concerne les requetes, une description de la session est necessaire 
dans le corps pour les messages d' initiation d'appel (requete invite), d'acquittement 
(requete ack) ou d' informations sur les caracteristiques d'un serveur (requete OPTIONS). 
Pour les messages d'enregistrement (requete register), d'annulation de requete (requete 
cancel) ou de terminaison d'appel (requete bye), le corps peut etre laisse vide. 

Pour leur part, les reponses, hormis quelques rares exceptions (par exemple les reponses 
de type 2xx pour valider l'annulation d'une requete ou la terminaison d'une session), 
comportent le plus souvent dans le corps du message des informations complementaires. 
Ces dernieres peuvent consister en une description des parametres que le terminal appele 
doit supporter (afin d'alleger les transmissions, en particulier en multicast, il est par 
exemple possible de n'inserer que les parametres qui varient par rapport a ceux proposes 
par 1' appelant dans sa requete) ou des services accessibles sur le serveur sollicite. Le cas 
echeant, le corps decrit le type d'erreur rencontre lorsque le serveur a tente d'executer la 
requete. 

Version du protocole 

La version du protocole SIP utilisee est toujours indiquee dans la ligne de requete ou 
d'etat du message. Autrement dit, elle est presente dans tous les messages SIP. Ainsi, les 
entites qui traitent les messages SIP peuvent rapidement savoir s'ils sont compatibles et 
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done s'ils sont susceptibles de communiquer par SIP avec l'emetteur du message re^u. 
La compatibilite n'est effective que si la version est strictement identique. 

Actuellement, e'est la version 2.0 qui est couramment utilisee. L' indication de la version 
doit se faire en specifiant le mot-cle SIP suivi d'une espace puis du numero de la version 
(SIP 2.0). 



Les requites SIP 



Comme indique precedemment, une requete est composee de trois parties : une ligne de 
requete, les champs d'en-tete du message et le corps. 

Les en-tetes et le corps ayant ete detailles precedemment, nous nous interessons ici a la 
ligne de requete specifique aux messages de requetes. 

La partie definissant la ligne de requete se compose des trois champs suivants illustres a 
la figure 4.9 : 

• methode, qui indique Taction sollicitee. 

• URI, qui precise le destinataire de la requete. 

• version, qui specifie le numero de la version du protocole SIP utilisee. 
Chacun de ces champs est separe par un separateur, ou SP (SeParator). 



Requete 




En-tete Corps 


\ 








Methode 






Version ^^^H 



Figure 4.9 

Format d'une requete SIP 



Les six methodes d'une requete SIP 

SIP n'utilise que six methodes fondamentales pour formuler ses requetes. Cela indique 
tres nettement la volonte de simplicite de ses concepteurs. 

Ces methodes sont detaillees dans la RFC 3261. Elles doivent etre supportees par tous les 
terminaux et serveurs sollicites. A ces methodes fondamentales, ont ete ajoutees des 
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methodes supplementaires, destinees a diverses ameliorations, qui ne sont pas forcement 
implementees par tous les terminaux. 

Notons que l'etablissement d'un appel peut ne faire intervenir que trois de ces methodes 
fondamentales (invite, ack et bye). 

Initier une session avec INVITE 

La methode invite permet d' initier une communication en invitant un correspondant a y 
participer. Elle peut aussi etre utilisee pour une conference afln d'inviter plusieurs inter- 
locuteurs a communiquer au sein d'une meme session. 

Le corps du message de cette methode fournit a l'appele les parametres de session 
souhaites et supportes par 1' appelant. Ce dernier specifiera, par exemple, le codec 
souhaite et le type de flux requis (voix, video, etc.). En regie generale, 1' appelant ne se 
contente pas d'une seule proposition, mais offre de multiples possibilites de parametres. 
Ses preferences sont definies par l'ordre dans lequel apparaissent ses propositions. 

Notons qu'une autre utilisation classique de cette methode consiste a renegocier dynami- 
quement de nouveaux parametres de session. Par exemple, si, durant une session deja 
etablie, Tun des interlocuteurs souhaite enrichir la voix par la video, il fait sa demande 
par une requete d' invitation. 

Confirmer les parametres de session avec ACK 

La methode ACK correspond a un acquittement de 1' appelant. Elle peut etre utilisee dans 
les deux cas de figure suivants : 

• Elle fait suite a l'acceptation d'un appel par l'appele. Avec la methode d'invitation, 
l'emetteur a fait connaitre au recepteur les parametres qu'il supporte et ses prefe- 
rences. En reponse, le recepteur en a fait autant. Au final, l'emetteur compare les para- 
metres supportes par les deux terminaux et indique par la methode ACK ceux qui seront 
utilises. Dans le corps de ce message, la methode decrit l'ensemble des parametres de 
session a adopter au cours de la session. Si le corps de la methode d' acquittement est 
vide, les parametres proposes par 1' appelant pourront etre adoptes pour la session. 

• Elle fait suite a une reponse de localisation fournie par un serveur de redirection. Une 
fois la determination de la position de l'appele effectuee, le serveur de redirection 
retourne le resultat a l'UAC (User Agent Client). Celui-ci valide la reception de ce 
resultat par la methode ack. 

S'informer sur le serveur avec OPTIONS 

La methode options permet d'interroger un serveur SIP, y compris l'entite UAS (User 
Agent Server) sur differentes informations. Elle comporte globalement deux volets : 
l'etat du serveur et ses capacites. 

Par exemple, cette methode offre la possibilite de savoir si un utilisateur que Ton 
souhaite appeler est present, c'est-a-dire disponible pour initier une communication. 
Cette reponse est pratique en ce qu'elle donne des informations sur un serveur, sans avoir 
a initier une communication pour autant. Autrement dit, la requete ne fait pas sonner le 
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poste du recepteur, puisqu'elle n'etablit pas d'appel, mais agit comme un indicateur de 
presence. 

Avec cette methode, il est possible d'obtenir des informations sur un serveur relativement 
aux types de medias supportes (audio, video, donnees), aux codecs supportes, aux 
methodes supportees et aux options d'appels, si le serveur en a diffuse. Le serveur qui 
re^oit cette requete repond par son etat et ses capacites. 

Terminer une session avec BYE 

La methode bye permet de liberer une communication. 

Cette requete peut etre emise indifferemment par 1' appelant ou par l'appele. Elle 
n'attend pas d'acquittement, puisqu'une terminaison d'appel peut etre decidee unila- 
teralement. 

Abandonner une demande avec CANCEL 

Cette methode annule une requete dont la reponse n'est pas encore parvenue au demandeur. 

Elle ne permet pas d'interrompre une session, mais indique que la reponse n'est plus 
attendue et qu'il n'est done pas necessaire de traiter la requete. 

Par exemple, une demande de recherche d'un utilisateur peut sollicker plusieurs serveurs 
de localisation en parallele, qui vont tous rechercher la presence de l'abonne dans leur 
base de donnees et retourner le resultat de la recherche. Des qu'un serveur a trouve 
l'abonne, les autres serveurs n'ont plus besoin de poursuivre leur recherche. Un message 
d'annulation leur est done envoye. 

Autre exemple, si un utilisateur envoie un message d'invitation invite et qu'il attende la 
reponse de l'appele, il peut a tout moment emettre un message cancel afin d'annuler 
1' invitation sans avoir a attendre la reponse de 1' appelant. 

La methode CANCEL est necessairement acquittee par un message ACK pour signifier que 
l'annulation est prise en compte. 

Enregistrer sa localisation avec REGISTER 

Cette methode permet d' enregistrer son adresse IP aupres d'un serveur d'enregistrement. 
Elle permet done d' assurer le service de localisation. 

L' information enregistree correspond a une entree dans la base specifiant la correspon- 
dance d'une adresse SIP avec une adresse IP. 

Cette entree a une duree de vie limitee. Passe ce delai, le serveur de localisation la 
supprime de sa base de donnees. Par defaut, la duree est d'une heure. Periodiquement, 
chaque terminal doit rafraichir cette entree pour la conserver en base ou, s'il est mobile, 
la modifier le cas echeant. 

Une autre maniere de gerer la duree de vie de l'enregistrement est d'utiliser le champ 
expire de la methode afin d'imposer une duree de validite fixe, qu'il n'est pas necessaire 
de mettre a jour. Le risque dans ce cas est que si l'abonne se deconnecte du reseau sans 
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l'indiquer au serveur d'enregistrement, il reste considere comme actif dans le reseau (une 
tentative infructueuse de communication est initiee). 

Methodes d'extension du protocole SIP 

Plusieurs methodes complementaires ont ete definies comme des extensions aux methodes 
precedentes afin d'enrichir les communications SIP. 

Leur implementation n'est toutefois pas systematique, et certains terminaux peuvent ne pas 
en supporter certaines. Neanmoins, ces methodes apportent des fonctionnalites pratiques. 

Les huit methodes d'extension classiquement utilisees sont les suivantes : 

• info. Decrite dans la RFC 2976, cette methode donne des informations complemen- 
taires sur la session en cours (puissance de reception, qualite du son, codecs utilises, 
etc.). Seules des donnees informatives sont envoyees en reponse a cette commande, ce 
qui ne modifie aucunement la session en cours. 

• refer. Decrite dans la RFC 3515, cette methode permet d'indiquer au recepteur du 
message une ressource. Elle autorise de la sorte differents services de relais, en parti- 
culier la redirection d'appel. 

• update. Decrite dans la RFC 3311, cette methode met a jour les parametres d'une 
session multimedia. 

• prack. Decrite dans la RFC 3262, cette methode fournit une securisation des reponses 
provisoires. PRACK est l'acronyme de Provisional Reliable ACK. 

• message. Decrite dans la RFC 3428, cette methode est utilisee pour l'envoi de 
messages instantanes. Le contenu de cette methode peut etre fait en MIME, ce qui 
offre une liberte pour le transport des differents types de contenus. 

• subscribe. Decrite dans la RFC 3265, cette methode permet de demander une notifi- 
cation d'evenement. Un client envoy ant au serveur cette requete reclame d'etre 
informe lorsque certains evenements surviennent. Par exemple, un utilisateur peut 
souhaiter etre averti lorsqu'un de ses contacts termine sa communication en cours. II 
interroge alors le serveur pour lui demander d'etre prevenu lorsque le contact devient 
disponible. Si le serveur accepte cette demande, il notifie les evenements correspon- 
dant a l'abonnement de l'utilisateur pendant toute la duree specifiee dans le champ 
expires insere dans l'en-tete du message. Au-dela de cette duree, la notification n'est 
plus active. La notification est effectuee par le serveur au moyen de la commande 

NOTIFY. 

• notify. Decrite dans la RFC 3265, cette methode permet de recevoir une notification 
pour les evenements auxquels on a souscrit. Lorsqu'un client a envoye une demande 
de notification d'evenement par la methode SUBSCRIBE, le serveur concerne lui envoie 
les notifications reclamees par la methode notify. 

• publish. Decrite dans la RFC 3903, cette methode permet d'afficher l'etat d'une 
requete a laquelle on a souscrit par la methode subscribe. 
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Un message de requete complet serait de la forme suivante : 



INVITE 


s 


1p 


laurent@reseau_labo.fr SIP/ 2.0 


From : 






Guy <sip : guy@reseau_labo.fr> 


To : 






Laurent <sip : laurent@reseau_labo.fr> 


Call -ID : 






3210-zad-323-lol@ reseau_labo.fr 


CSEQ : 






123 INVITE 


Subject : 






Reunion d'equipe demain. 


VIA : 






SIP/2.0/UDP 192.168.l.3@reseau_labo.fr 


Expire : 






7200 


Content-Type: 






application/ SDP 


Content Lenght : 






13232 


v= 








o= IN IP4 132.227. 


60 


2 




s= Test de To IP 








c= IN IP4 proxllAB 


.1 


ip6 


fr 


m= audio 4142 RTP 









Les reponses SIP 

Quelle que soit la methode utilisee dans une requete, le recepteur final doit y apporter au 
moins une reponse en retour, ne serait-ce qu'une reponse temporaire pour informer 
l'emetteur que sa requete est prise en compte et en train d'etre traitee et qu'elle sera 
suivie d'une reponse finale des que possible. 

Les reponses sont classees en categories, suivant leur type. Elles peuvent au besoin etre 
completees par un message plus explicite. 

Les reponses SIP doivent respecter le format illustre a la figure 4.10. 



Figure 4.10 

Format des reponses SIP 
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Les reponses aux requetes SIP debutent par une ligne d'etat (Status Line), laquelle 
comporte les trois champs suivants : 

• Version : c'est la version du protocole SIP utilisee. 

• Code d'etat {Status Code) : code numerique a trois chiffres speciflant la reponse 
donnee a la requete. Cet entier est code sur trois bits. 

• Raison {Reason Phrase) : message textuel expliquant brievement le code d'etat de la 
reponse. Fonctionnellement parlant, il s'agit d'un element redondant par rapport au 
code d'etat. Le protocole offre neanmoins ainsi un niveau de clarte plus accessible, qui 
favorise la comprehension des messages protocolaires par les utilisateurs comme par 
les programmeurs. Son utilite n'est pas protocolaire mais informative. 

II existe six classes de reponse dans lesquelles sont repertories tous les messages de 
retour possibles. Le premier chiffre de chaque code specifie la categorie a laquelle appartient 
le code. 

Le tableau 4.6 recapitule les principaux codes d'etat et leur raison respective, utilises 
dans les messages de reponse SIP par les entites SIP (incluant les UAS comme n'importe 
quel serveur SIP dedie). 



Tableau 4.6 - Principaux codes d'etat et raisons d'une reponse SIP 



Code d'etat Raison 


Commentaire 


Ixx - Messages d'information 

La requete est en cours de traitement. C'est 

finale, correspondant a toute autre categorie 


une reponse temporaire, qui est purement informative. Une reponse definitive (ou 
que 1xx) devra etre emise au plus tard dans 200 ms. 


100 TRYING 


Tentative d'appel en cours 


180 RINGING 


Le poste de I'appele est en train de sonner. 


181 CALL IS BEING FORWARDED 


Lappel est en train d'etre redirige vers la position actuelle de I'appele. 


182 QUEUED 


L'appelant n'est pas disponible. Lappel n'est pas rejete pour autant mais 
simplement mis en attente. 


2xx - Messages de succes 

La requete a ete regue, comprise et acceptee par le serveur. 


200 ok 


La requete a ete executee avec succes. 


3xx - Messages de redirection 

Decrit une autre action a effectuer avant de finaliser la requete. Cela peut etre une nouvelle position de I'utilisateur qui est retour- 

nee ou bien une information sur un autre service impose ou propose pour satisfaire I'appel. 


300 multiple choices 


La resolution d'adresse de I'appele a conduit a plusieurs localisations pos- 
sibles, toutes retournees a l'appelant afin qu'il en choisisse une. 


301 moved permanently 


Lappele n'est plus disponible a la localisation demandee. Une nouvelle locali- 
sation est envoyee pour inviter l'appelant a le contacter a cette adresse. 


302 moved temporarily 


Lappele est temporairement indisponible a I'adresse specifiee. Une nou- 
velle localisation est specifiee a l'appelant. 


305 use proxy server 


Lappelant doit imperativement utiliser un proxy pour pouvoir contacter I'appele. 


380 alternative service 


Lappel n'a pas abouti, mais d'autres services sont disponibles pour l'appe- 
lant s'il le souhaite. Ces services sont listes dans le corps du message. 
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Tableau 4.6 - Principaux codes d'etat et raisons d'une reponse SIP (suite) 



Code d'etat 


Raison 


Commentaire 


4xx - Messages d'erreurs : erreurs du client ou requetes ne pouvant etre prises en charge 

La syntaxe est erronee ou la requete ne peut etre prise en charge. Dans ce cas, I'appelant ne doit renvoyer la meme requete que 

s'il a fait une modification ou passe un certain delai ou encore sollicite un autre serveur. 


400 


BAD REQUEST 


Le format de la requete est incorrect et ne peut etre compris. Le message 
devrait inclure des informations sur la partie de la requete qui pose probleme. 


401 


UNAUTHORIZED 


Une authentification est requise pour pouvoir effectuer I'execution de cette 
requete. Cette reponse est emise soit par un serveur d'enregistrement, soit 
par un UAS. 


402 


PAYMENT REQUIRED 


Un paiement est necessaire pour effectuer I'execution de cette requete 
(destine a un usage futur). 


403 


FORBIDDEN 


Le service demande est regu et compris, mais son execution est interdite. 


404 


NOT FOUND 


Lappele n'a pas ete trouve a I'URI specifie. 


405 


METHOD NOT ALLOWED 


La methode sollicitee n'est pas supportee. Une liste des methodes qui le 
sont est fournie dans le corps du message de reponse a la requete. 


406 


NOT ACCEPTABLE 


Le champ d'en-tete accept de la requete impose un format qui ne peut etre 
respecte dans la reponse. 


407 


PROXY SERVER AUTHENTICATION 
REQUIRED 


Une authentification est requise pour effectuer I'execution de cette requete. 
Cette reponse est emise par les serveurs proxy exclusivement (contraire- 
ment au code 401). 


408 


REQUEST TIMEOUT 


La requete necessite un temps de traitement trop long (par exemple, la 
localisation d'un abonne). 


410 


GONE 


Lappele n'est definitivement plus disponible a I'URI specifie. Si le caractere 
permanent est incertain, une erreur de code 404 est utilisee. 


413 


REQUEST ENTITY TOO LARGE 


Le serveur ne peut prendre en charge une requete dont le corps est aussi gros. 


414 


REQUEST-URI TOO LONG 


LURI est trop long pour etre interprets par le serveur. 


415 


UNSUPPORTED MEDIA TYPE 


Le format du corps du message de requete n'est pas pris en charge par le 
serveur pour cette requete. Le serveur doit retourner la liste des formats qu'il 
supporte dans les champs accept, accept-encoding ou accept-language. 


416 


UNSUPPORTED URI SCHEME 


Le serveur ne supporte pas la forme de I'URI indique dans la requete. 


420 


BAD EXTENSION 


Dans I'en-tete require ou proxy-require une extension d'un protocole 
inconnu est specifiee. Le serveur doit indiquer dans sa reponse les exten- 
sions qu'il ne supporte pas. 


421 


EXTENSION REQUIRED 


La specification d'une extension est indispensable pour I'execution de la 
requete. 


423 


INTERVAL TOO BRIEF 


La duree d'expiration specifiee dans le message est trop courte pour etre 
prise en compte. Typiquement, un enregistrement dans le serveur de locali- 
sation qui a une duree de validite trop courte peut etre refuse par le serveur. 


480 


TEMPORARILY NOT AVAILABLE 


Lappele a ete contacte, mais il est temporairement indisponible et ne peut 
prendre la communication. 


481 


CALL LEG/TRANSACTION DOES NOT 
EXIST 


La requete fait reference a une autre requete dont I'identifiant est inconnu. 
Typiquement, une requete de type bye ou cancel dont le Call-Id n'existe 
pas est invalide. 
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Tableau 4.6 - Principaux codes d'etat et raisons d'une reponse SIP (suite) 



Code d'etat 


Raison 


Commentaire 


482 


LOOP DETECTED 


Une boucle a ete detectee dans le routage de la requete. Concretement, le 
serveur qui receptionne une requete retrouve sa propre adresse dans le 
chemin parcouru (champ via), ce qui indique qu'il Pa deja traitee. 


483 


TOO MANY HOPS 


Trop de noeuds intermediates sont requis pour le traitement de la requete. 
C'est le champ max forwards qui specifie le nombre de noeuds de transit 
maximal des requetes. 


484 


ADDRESS INCOMPLETE 


Ladresse de localisation specif iee pour la personne appelee est incomplete. 


485 


AMBIGUOUS 


La localisation de I'appele presente une ambigulte qui ne peut etre resolue . 
Les differentes interpretations de cette localisation sont fournies quand 
c'est possible. 


486 


BUSY HERE 


Lappele a ete contacte, mais il est occupe et ne peut prendre la communi- 
cation. 


487 


REQUEST TERMINATED 


La requete a ete terminee par la reception d'un message bye ou cancel. 


488 


NOT ACCEPTABLE HERE 


Lappele a ete joint, mais certains parametres de session ne peuvent etre 
mis en oeuvre et doivent etre changes. Identique au message 606, si ce 
n'est qu'il ne s'applique qu'a la ressource specifiee dans I'URI. 


5xx - Messages d'erreurs : erreur du serveur 
La requete est correcte, mais le serveur n'a pas 


reussi a la traiter, car le service n'est plus disponible sur le serveur sollicite. 


500 


INTERNAL SERVER ERROR 


Une erreur de nature non previsible est survenue et empeche la realisation 
de I'execution. 


501 


NOT IMPLEMENTED 


La requete n'est pas implemented sur le serveur qui la regoit. 


502 


BAD GATEWAY 


Le serveur, agissant en tant que passerelle ou proxy, a regu une reponse 
invalide en essayant de relayer la requete pour la traiter. 


503 


SERVICE UNAVAILABLE 


Le service n'est pas disponible en ce moment, peut-etre par surcharge du 
serveur, maintenance ou dysfonctionnement. 



504 



GATEWAY TIMEOUT 



La requete a fait appel a une demande dont la reponse n'est pas parvenue 
dans le delai attendu. Typiquement, un serveur proxy qui interroge un ser- 
veur de localisation peut retourner ce code s'il n'a pas regu de reponse 
passe un temps determine. 

sip version not supported La requete specifie une version du protocole SIP qui n'est pas prise en 

charge par le serveur charge de son execution. 

6xx - Messages d'erreurs : echec general 

Aucun serveur ne peut traiter cette requete, car ils sont occupes, inaccessibles ou refusent I'appel. La syntaxe de la requete n'est 

pas en cause. 



505 



600 

603 
604 

606 



BUSY EVERYWHERE 



DECLINE 

DOES NOT EXIST ANYWHERE 



not acceptable 



Lappele a ete joint, mais il est occupe sur tous les postes et ne peut prendre 
la communication. 

Lappele a ete joint, mais il a refuse la communication. 

Le serveur qui a autorite sur la gestion du compte de I'appele informe 
I'appelant que I'appele n'existe pas dans le reseau. 

Lappele a ete joint, mais certains parametres de session ne peuvent etre 
mis en oeuvre, quelle que soit la localisation, et doivent etre changes. 



Theorie de la TolP 



Parte I 



On remarque que ces codes d'erreur sont semblables a ceux utilises par le protocole 
HTTP version 1.1 (RFC 2616), soulignant un effort de generalisation delibere. Nean- 
moins, le protocole SIP ne s'approprie pas tous les codes de HTTP 1.1, certains etant 
inappropries. Inversement, il etend les reponses possibles avec HTTP 1.1, avec, d'une 
part, des messages speciflques (tous les codes superieurs ou egaux a x80, avec x prenant 
une valeur comprise entre 1 et 5, sont propres a SIP) et, d' autre part, une nouvelle classe 
de message (la classe 6 est speciflque a SIP). Tout code d'etat non reference et regu par 
un terminal est interprets comme etant equivalent au code xOO. 

Un message de reponse complet serait de la forme suivante : 



SIP/ 2.0 


180 Ringing 


VIA : 


SIP/2.0/UDP 192.168.l.18@reseau_labo.fr 


From : 


Guy <sip : guy@reseau_labo.fr> 


To : 


Laurent <sip : laurent@reseau_labo.fr> 


Call -ID : 


3210-zad-323-lol@ reseau_labo.fr 


CSEQ : 


123 INVITE 


Expires : 


7200 



Scenarios de communication 

Nous allons illustrer la succession chronologique des messages de requetes et de repon- 
ses dans les six scenarios classiques suivants : 

1. Initialisation d'une communication directe. 

2. Enregistrement d'un terminal. 

3. Initialisation d'une communication avec un serveur proxy. 

4. Localisation par un serveur de redirection et initialisation d'appel directe. 

5. Modification dynamique d'une communication SIP. 

6. Terminaison d'une communication. 

t. Initialisation d'une communication directe 

Une communication peut s'effectuer directement entre deux correspondants, sans faire 
intervenir d' autre entite. 

Dans ce cas, 1' appelant doit connaitre la localisation (sous forme d'adresse IP) de la 
personne qu'il souhaite contacter. 
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La figure 4.11 illustre ce scenario. 



Figure 4.11 

Initiation d'une 
communication directe 



Terminal SIP 

Appelant 

{UAC) 



C 



Invite 

180 Ringing 
200 OK 



Terminal SIP 
Appele 
(UAS) 




Flux multimedia (audio, video, texte, ...) 



-> 



Cette communication reflete la simplicite d' utilisation du protocole SIP. 
Quatre etapes seulement suffisent a mettre en relation les deux utilisateurs : 

1. L' appelant (UAC) envoie un message (requete invite) proposant a son correspondant 
(UAS) d'initier une communication. Ce message contient les parametres desires pour 
etablir la communication. 

2. Des que l'UAS regoit le message, il en informe l'utilisateur appelant (le telephone 
sonne, avec indication de 1' appelant et du motif de son appel s'il a renseigne ce 
champ, ainsi que des services disponibles). Dans le meme temps, il indique a 1' appe- 
lant (par une reponse provisoire 180 ringing) que l'appele est en train d'etre averti 
de 1' appel. 

3. Des que l'appele accepte l'appel (en decrochant), l'UAS informe l'appelant (par une 
reponse definitive 200 ok) que l'appel peut debuter. Ce message contient les parame- 
tres que l'UAS supporte pour la session. 

4. L'UAC retourne a l'UAS un message d'acquittement (requete ack) lui indiquant 
qu'il a pris note que l'appel peut debuter. Ce message comporte les parametres fixes 
pour la session, qui tiennent compte de ces possibilites et de celles de l'UAS. 

Les intervenants sont ensuite mis en relation et peuvent communiquer. 
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2. Enregistrement d'un terminal 

Lorsqu'un terminal est active dans un reseau, sa premiere action consiste a se declarer 
aupres d'un serveur d' enregistrement, de maniere a etre disponible si un appelant 
souhaite le joindre. 

Ce scenario est illustre a la figure 4.12. 



Figure 4.12 

Enregistrement 
d'un terminal SIP 



t- . x ~ Serveur Serveur 

Terminal Serveur proxy „ >. . * * s . .. 

r r d enregistrement de ocahsatton 




Base de 
localisation 



Le serveur de localisation maintient dans sa base de donnees une entree associant 
ridentifiant d'un utilisateur avec sa position dans le reseau (adresse IP du terminal de 
l'utilisateur, port utilise par l'application SIP et identifiant de l'utilisateur sur ce 
poste). 

Cette entree sera du type indique au tableau 4.7. 



Tableau 4.7 Entree dans le 


serveur de localisation permettant de localiser un utilisateur 


Utilisateur 


Localisation 


Delai d'expiration 


sip:albert@mon_domaine. fr 


sip:albert@1 32.227. 155. 155:12345 


48 minutes 



Notons la presence d'un delai d'expiration, ici arbitrairement fixe a 48 minutes (par 
defaut, une entree est valable pendant une heure). Periodiquement, le terminal doit rafrai- 
chir son entree a l'aide de la requete register afin de manifester sa presence. A defaut, 
1' entree est effacee. 



3. Initialisation d'une communication SIP avec un serveur proxy 

Les etapes et messages envoyes pour initier une session entre deux correspondants dans 
le cas ou un proxy est utilise sont illustres a la figure 4.13. 

Dans cet exemple, Anne souhaite ouvrir une session avec Brigitte. Comme elle ne 
connait pas la localisation de cette derniere, elle sollicite son proxy afin de la determiner. 
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Terminal 
de Anne 



Serveur proxy 
de Anne 



Serveur proxy 
de Brigitte 



Terminal de 
Brigitte 



Etape 1 




Attente de 
la reponse 
de Brigitte 



Figure 4.13 

Initialisation d'un appel avec un proxy 



Les etapes suivantes sont necessaires : 

1. Anne compose sur son terminal l'adresse SIP de Brigitte. Cette derniere n'est pas 
necessairement une adresse IP et peut etre un identiflant qu'il faut resoudre. Un mes- 
sage d' invitation (requete invite) est envoy e de l'UAC d'Anne vers son serveur 
proxy SIP. L'adresse du proxy d'Anne peut etre configuree sur son terminal ou etre 
automatiquement distribute, par DHCP par exemple. A reception de ce message, le 
serveur proxy d'Anne utilise la partie domaine de l'adresse SIP de Brigitte pour 
determiner le serveur en charge de la gestion du compte de Brigitte (c'est-a-dire en 
charge du domaine de Brigitte). A cette fin, un serveur DNS peut etre sollicite pour 
localiser le serveur proxy de Brigitte. En parallele, le serveur proxy informe Anne 
qu'il prend en charge la requete et tente de la mettre en relation. La reponse tempo- 
raire 100 trying indique a cette derniere que le message a ete re^u et qu'il est en 
cours de traitement. 

2. Routage du message d'invitation. Le serveur proxy d'Anne transmet l'invitation au 
serveur proxy de Brigitte apres 1' avoir localise. C'est le message d'invitation original 
qui est integralement relay e du proxy d'Anne vers celui de Brigitte. La seule modifi- 
cation apportee au message par le premier serveur proxy concerne le champ VIA, qui 
liste 1' ensemble des machines parcourues lors de l'acheminement du paquet, et 
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auquel il ajoute sa propre adresse reseau (en plus de celle d' Anne, qui y figure initia- 
lement). Le serveur proxy de Brigitte informe le serveur proxy d' Anne (par un mes- 
sage de reponse temporaire 100 trying) de la reception de la requete et de la 
tentative d' initialisation. Parallelement, il recherche la localisation du terminal de 
Brigitte en utilisant le service de localisation. Une fois la position du terminal 
dans le reseau trouvee, il lui transmet l'invitation d' Anne. A nouveau, ce message est 
conforme a 1' original, et seul le champ VIA a ete enrichi de 1' adresse du serveur 
proxy de Brigitte. 

3. Le terminal de Brigitte sonne. Le telephone de Brigitte (eventuellement un soft- 
phone) re^oit l'invitation et la fait connaitre a l'utilisateur Brigitte, le plus souvent 
par une sonnerie. En parallele, il indique a son proxy (par un message 180 ringing) 
que l'appel est en train d'etre notifie a Brigitte et que la communication est en attente 
de son acceptation. Ce message informatif est relaye jusqu'a l'emettrice Anne, qui 
re^oit generalement un retour audio ou visuel (une tonalite de sonnerie particuliere le 
plus souvent). L' utilisation du champ d'en-tete VIA permet de remonter de proche en 
proche jusqu'a Anne selon le meme chemin. 

4. Brigitte repond au telephone. On suppose le cas ou Brigitte a choisi de repondre a 
l'appel. A l'instant ou elle decroche, l'UAS retourne a l'UAC un message 200 OK 
pour l'informer que l'appel est accepte. Ce message est relaye par les differents 
proxy. A ce stade, la communication n'a pas encore debute, et aucun son n'est 
transmis. 

5. Le terminal d'Anne confirme les parametres d'appel. En tenant compte des capa- 
cites prises en charge par les correspondants, le terminal d'Anne envoie un mes- 
sage d'acquittement ACK qui specifie les parametres definitifs a utiliser lors de 
cette session. Notons que le message d'acquittement peut passer directement d'un 
interlocuteur a 1' autre, sans transiter par les serveurs proxy. A ce stade, chacun 
des utilisateurs a pu apprendre la localisation exacte de son interlocuteur, et il 
n'est done plus necessaire de recourir aux serveurs proxy. Toutes les transactions 
qui suivent sont effectuees directement, de poste utilisateur a poste utilisateur. 
Ainsi, les serveurs proxy sont sollicites au minimum. De la meme maniere, pour 
ne pas saturer les serveurs proxy inutilement, les flux de donnees multimedias ne 
transitent jamais par eux. 

A reception de ce message, la communication entre les interlocuteurs peut debuter. Tous 
ces echanges n'ont reclame que quelques millisecondes, imperceptibles pour les 
intervenants. 

Globalement, on retrouve dans cet appel, les trois phases fondamentales de l'appel direct 
entre les correspondants : 

1. Requete invite : invitation de 1' appelant. 

2. Reponse 200 OK : acceptation par l'appele. 

3. Acquittement ACK : confirmation par 1' appelant. 
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II s'agit des trois messages necessaires a la modification dynamique d'une communica- 
tion SIP. Les autres messages concernent essentiellement la localisation ou sont a titre 
informatif. 

4. Localisation par un serveur de redirection et initialisation d'appel 
directe 

La figure 4.14 illustre le scenario ou un serveur de redirection est utilise par le terminal 
appelant afin de localiser son correspondant et pour l'echange qui s'ensuit. L'objectif est 
toujours de mettre en relation le terminal d' Anne avec celui de Brigitte, mais par un autre 
moyen. 
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Figure 4.14 

Localisation avec un serveur de redirection et initialisation d'appel 



Dans la premiere etape, le terminal d' Anne sollicite le serveur de redirection pour deter- 
miner la localisation du terminal d'Anne. Une fois cette recherche effectuee, la reponse 
est envoyee directement au terminal d'Anne, lequel initie l'appel lui-meme, en contactant le 
serveur proxy de Brigitte. 
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Les etapes qui suivent sont identiques a celles du scenario precedent avec 1' initialisation 
d'appel par un serveur proxy, si ce n'est que ce dernier n'intervient pas dans les echanges 
intermediaries. 



5. Modification d'une communication SIP 

Lorsqu'un utilisateur est en communication, il peut arriver qu'il souhaite modifier les 
parametres de cette communication tout en la conservant active. Par exemple, s'il 
commence un telechargement et que son debit risque de diminuer en consequence, il peut 
souhaiter utiliser un codec moins gourmand. Dans un autre cas, l'utilisateur peut vouloir 
enrichir la communication audio avec une diffusion video. Ou encore, il peut souhaiter 
inviter a une conference un nouveau correspondant, qui ne supporte pas le codec utilise 
par les autres conferenciers. 

Ces cas sont parfaitement envisageables avec le protocole SIP, qui offre, rappelons-le, 
une tres grande souplesse. A tout moment, 1' appelant ou l'appele peut envoy er un 
nouveau message d' invitation, avec la requete invite, arm de renegocier les parametres 
de la communication. Bien sur, dans ce contexte, le message n'a pas pour objectifd' inviter a 
une nouvelle session, mais d'utiliser de nouveaux parametres. 

C'est pour cette raison qu'on nomme re-invite ce type de requete d'invitation. Du reste, la 
communication en cours n'est pas interrompue par la reception de cette requete. S'il accepte 
les modifications sollicitees dans la requete d'invitation, le recepteur conflrme son accord 
par l'envoi d'une reponse 200 OK, qui sera ensuite acquittee par le demandeur, comme pour 
l'initiation d'une communication (voir figure 4.15). Dans ce contexte, cette requete ne fait 
pas sonner le poste de l'interlocuteur puisque la communication est deja en cours. 



Figure 4.15 

Requete re-invite acceptee 



Terminal SIP 




Dans le cas contraire, ou le recepteur ne supporte pas ou ne souhaite pas accepter la 
modification de la session en cours, il reste libre de le faire, sans pour autant mettre fin a 
la communication, en envoyant un message de reponse 488 not acceptable here, 
comme l'illustre la figure 4.16. 
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Figure 4.16 

Requite re-invite refusee 
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Invite 
488 Not Acceptable Here 




Le demandeur qui en prend connaissance ne peut effectuer la modification desiree et doit 
soit se contenter des parametres de la session actuelle, soit faire une nouvelle offre, en 
suggerant l'utilisation d'autres parametres. 



6. Terminaison d'une communication SIP 

La figure 4.17 illustre la terminaison d'une session a 1'initiative de n'importe quelle 
entite souhaitant mettre fin a l'appel. 



Figure 4.17 

Terminaison d'une 
communication 




Cette operation ne comporte que les deux etapes tres simples suivantes : 

1. Un message (requete bye) est envoy e pour indiquer au correspondant que la session 
va etre cloturee. 

2. Le correspondant repond a cette requete en validant la prise en compte de cette 
demande par une reponse 200 OK. 

La communication entre les intervenants est alors rompue. 
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Conclusion 



Indiscutablement, le protocole H.323 possede une avance historique par rapport au proto- 
cole SIP. Son interaction avec les reseaux telephoniques RTC est parfaitement maitrisee, 
alors qu'elle n'est pas totalement specifiee avec le protocole SIP. Globalement, H.323 est 
plus riche en termes de fonctionnalites que SIP. 

Les deux protocoles de signalisation disposent de mecanismes d'extensibilite : avec 
H.323 les parametres nonstandardParam (definit en ASN.l) peuvent contenir des 
codes personnalises pour y developper des extensions. De meme, SIP herite du meca- 
nisme PEP (Protocol Extension Protocol) de HTTP permettant de definir des pointeurs 
documentant des caracteristiques complementaires. La compatibilite avec H.323 est 
complete, quoique souvent laborieuse, puisqu'elle impose de respecter des fonctionnali- 
tes lourdes qui ont ete ameliorees mais doivent toujours etre supportees. Au contraire, la 
compatibilite avec SIP n'est pas explicitement requise, ce qui allege les implementations 
du protocole tout en restreignant son cadre d' application. 

Mais SIP possede des arguments solides qui plaident en sa faveur : plus souple, rapide et 
modulaire que ne Test H.323, le protocole SIP beneficie d'un heritage protocolaire issu 
du monde Internet. II s'integre simplement dans un reseau IP et proflte d'une architecture 
distribute pour s' adapter facilement a la montee en charge d'utilisateurs au sein d'un 
reseau. 

SIP etend meme ses possibilites par de nouveaux protocoles qui s'appuient sur les fonc- 
tionnalites de SIP et ses capacites pour de nouvelles applications. C'est le cas du proto- 
cole SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) qui 
utilise SIP pour gerer la messagerie instantanee et la fonctionnalite de presence. SIMPLE 
est etudie au sein du groupe de travail IMPP (Instant Messaging and Presence Protocol) 
de 1'IETF, et est soutenu par d'importants industriels, tels que Microsoft ou Lotus. 

En outre, la mobilite est une notion centrale dans SIP : un meme utilisateur peut etre joint 
par differents moyens, par exemple a son domicile ou a son lieu de travail, ou encore sur 
son telephone fixe, son telephone portable ou son assistant personnel. En conservant une 
meme identite, le protocole SIP determine la localisation reelle de l'utilisateur : c'est la 
notion de personnal mobility. 

Pour toutes ces raisons, SIP a aujourd'hui les faveurs des industriels et s'impose progres- 
sivement aupres des acteurs de la TolP, tandis que H.323 se marginalise dans les 
nouveaux produits et installations. Ainsi, des fournisseurs d'acces ADSL, tels que Free et 
Neuf Telecom, l'ont choisi pour assurer la signalisation de leur service de telephonie IP. 
De meme, Microsoft utilise SIP dans son serveur unifie de communications multimedias 
LCS (Live Communications Server). 

Le protocole SIP constitue done un solide concurrent de H.323 : il repose sur des bases 
saines et solides, que devront conforter d'importants developpements pour completer les 
fonctionnalites de SIP attendues dans le futur. 



5 



Le protocole MGCP 



L'une des raisons qui expliquent l'emergence et le succes du protocole H.323 est le 
besoin de regrouper les differents acteurs du multimedia, qu'ils soient equipementiers ou 
fournisseur de services, autour de normes communes. La concurrence engendree par le 
protocole SIP a reduit cet effet d'universalite puisque les reseaux IP ont desormais une 
solide solution de rechange a H.323. 

Des lors, se pose la question de la communication entre des reseaux de nature differente 
(ATM, RNIS, RTC ou IP) ou bien de meme nature mais exploitant des protocoles de 
signalisation differents (H.323, SIP ou autre). 

Si les passerelles ont deja ete introduites avec le protocole H.323, elles demeurent des 
entites complexes, onereuses et non administrables, qui plus est fortement sollicitees 
alors qu' elles tiennent difflcilement la montee en charge. Pour combler ce nouveau 
besoin, le protocole MGCP (Media Gateway Control Protocol), ou protocole de controle 
des passerelles multimedias, a ete propose. 

II fonctionne au niveau applicatif et permet d'offrir une couverture plus large en federant 
toutes les signalisations, qu'elles soient de type IP ou RTC entre autres. C'est le maitre 
d'oeuvre de l'interoperabilite entre tous les protocoles de signalisation et tous les reseaux, 
de quelque nature qu'ils soient. 
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Comme l'illustre la figure 5.1, qu'il s'agisse de la signalisation SS7, utilisee dans un 
reseau commute, H.323 ou SIP, le protocole MGCP est congu pour relier et faire 
communiquer 1' ensemble de ces reseaux. 



Figure 5.1 

Role federateur 
du protocole MGCP 




Mgnde Telecom 
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MGCP est aujourd'hui massivement utilise par les fournisseurs d'acces Internet pour 
assurer le controle et 1' administration a distance des boitiers (box) mis a disposition de 
leurs abonnes. 

Apres un bref rappel historique, ce chapitre se penche sur les caracteristiques essentielles 
de MGCP, qui en font un protocole de choix pour les operateurs. 

Nous y detaillons successivement ses principales fonctionnalites, son architecture, ainsi 
que les echanges protocolaires utilises dans ses communications. 



Historique 



MGCP puise sa source dans une problematique de convergence des reseaux, que diffe- 
rents acteurs ont voulu resoudre independamment les uns des autres. Une fois encore, ces 
tentatives individuelles des constructeurs et equipementiers n'ont fait qu'accroitre les 
incompatibilites entre entites reseau. 

Fruit de reflexions communes, le protocole MGCP a synthetise des concepts enonces par 
differents groupes. 

Les travaux ont debute apres que le protocole H.323 eut ete propose par l'UIT. II est vite 
apparu que 1'initiative H.323 etait insatisfaisante pour relier a grande echelle des reseaux 
de natures differentes. Les passerelles (gateways) proposees dans 1' architecture H.323 
sont des elements complexes et couteux, ce qui pose probleme dans le monde IP. Plus le 
nombre de reseaux a traverser pour etablir une communication est important, plus Test 
aussi celui des passerelles sollicitees. 

Progressivement, un certain nombre d' initiatives ont vise a disposer d'un reseau dont 
toutes les passerelles multimedias soient des composants simples. L'idee-force etait de 
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relier ces passerelles a un controleur maitre concentrant toute l'intelligence du reseau et 
centralisant les decisions selon le modele maitre-esclave. 

L' architecture generate conceptualisant les entites de controleur et de passerelle multi- 
media, et plus generalement le modele maitre-esclave, fut initialement proposee dans le 
projet TIPHON (Telecommunications and Internet Protocol Harmonization Over 
Networks) de l'ETSI. La premiere tentative de protocole de communication entre ces 
entites fut SGCP (Simple Gateway Control Protocol), en 1997. Proposee par Telcordia 
(anciennement BellCoRe, acronyme de Bell Communications Research), elle re^ut le 
soutien de Cisco. TIPHON est le protocole precurseur de MGCP. 

En 1998, l'operateur de telecommunications Level 3 Communications (groupe XCOM 
Technologies) a mis en place un comite consultatif technique, ou TAC (Technical Advi- 
sory Council), reunissant une douzaine d'industriels renommes, comme Ericsson, 
Lucent, Nortel, Alcatel, 3Com et Cisco. Avec ces membres fondateurs, le TAC sera a 
l'origine de la conception d'un protocole de controle des entites reseau sur Internet, 
nomme IDCP (Internet Device Control Protocol). Ses specifications seront presentees a 
l'UIT, a 1'IETF eta l'ETSI. 

En octobre 1998, avec le soutien d'importants constructeurs, tels que Cisco et Alcatel, le 
protocole MGCP a ete standardise a 1'IETF par le groupe de travail MeGaCo (Media 
Gateway Control). Celui-ci realisait la fusion des initiatives SGCP et IDCP. MGCP 
s'inscrit dans la droite ligne de la version 1.1 du protocole SGCP, qui servira de socle 
principal a MGCP. 

En plus de deriver de SGCP, MGCP s'est enrichi de nombreuses fonctionnalites propo- 
sees dans IDCP. En octobre 1999, la RFC 2705 presentait la premiere version de MGCP. 
Elle sera rendue obsolete en Janvier 2003 par la RFC 3435, qui sera completee par la 
RFC 3661 en decembre 2003. 



H.248/MeGaCoP 



Parallelement a MGCP, Lucent Technologies proposait, en novembre 1998, MDCP 
(Media Device Control Protocol), un protocole analogue, dont la conception presentait 
des avantages notables, que MGCP ne pouvait prendre en compte sans repenser son 
modele. 

Pour synthetiser les efforts des protocoles MGCP et MDCP, le groupe de travail MeGaCo 
de 1'IETF et le groupe d'etude 16 (Study Group 16) de l'UIT-T deciderent de travailler de 
concert et de federer les differentes propositions emergentes au sein d'un protocole 
commun. Les travaux reprenaient ceux menes sur MGCP et y associaient un ensemble 
de nouveaux parametres, de codes d'erreurs et de procedures inspires de MDCP. 

L'UIT identifiera ce protocole sous la recommandation H.GCP (Gateway Control Proto- 
col), devenue ensuite H.248, tandis que 1'IETF referen^ait ce meme protocole sous 
1' appellation MeGaCoP (MeGaCo Protocol). En aout2000, 1'IETF publiait la 
RFC 2885, corrigee le meme mois par la RFC 2886, qui presentait le protocole MeGa- 
CoP version 0.8. En novembre 2000, la version 1 de MeGaCoP etait publiee dans la 
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RFC 3015, rendant obsoletes les RFC 2885 et 2886. Depuis 1' acceptation de cette RFC, 
le groupe de travail MeGaCo s'est dissout. 

MeGaCoP reste assez remarquable dans sa tentative de conceptualisation et de 
nomenclature des principales notions abordees dans MGCR Ainsi, de nouvelles 
terminologies sont apparues, certaines pour evoquer de nouvelles notions, d'autres 
uniquement pour renommer l'existant en harmonisant 1' ensemble des concepts afin de 
les generaliser. C'est ainsi, notamment, que l'entite de controle des passerelles fut 
appelee Call Agent dans MGCP puis MGC (Media Gateway Controller) dans la termi- 
nologie MeGaCo. 

La figure 5.2 illustre les heritages protocolaires entre ces differentes propositions. 

Figure 5.2 

Heritages protocolaires des 
differents standards autour de 
MGCP 
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Aujourd'hui, MGCP tient parfaitement son role, en depit de l'apparition du protocole 

H.248. 



Architecture et fonctionnement 

Pour communiquer entre deux reseaux de nature differente, il est necessaire d'utiliser 
une passerelle. Cette entite prend en charge a la fois la signalisation pour l'etablissement, 
la gestion et la terminaison de la communication, mais aussi la conversion des signaux 
pour l'adaptation des flux d'un reseau vers un autre. MGCP separe ces deux aspects en 
entites distinctes, l'une pour controler les appels, l'autre pour appliquer le controle 
ordonne par la premiere entite. 

MGCP fonctionne selon une architecture centralisee permettant de faire communiquer et 
de controler differentes entites appartenant a des reseaux distincts. II se fonde sur l'hypo- 
these que les terminaux des utilisateurs peuvent etre des composants de base, peu 
couteux et sans aucune intelligence, reduits a des fonctionnalites elementaires. 
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Les passerelles sont egalement des entites simples. En fournissant un service simple et 
generique, elles restent independantes de leur constructeur. Pour leur donner des directi- 
ves permettant le traitement des services, ces passerelles multimedias sont reliees a une 
entite centrale. Le protocole MGCP assure le controle et l'echange de messages de signa- 
lisation entre ces passerelles, reparties dans un reseau IP, et le controleur de passerelles, 
charge de 1' administration et de la gestion dynamique des passerelles. 

MGCP fait eclater le modele architectural propose avec H.323 en decomposant le role 
des passerelles et en externalisant toute leur intelligence sur une entite centrale. 

Pour realiser cette distinction, MGCP definit les entites suivantes : 

• Le Call Agent, qui sert a piloter et administrer les passerelles de maniere centralisee. 

• Les passerelles, qui maintiennent la connectivity entre reseaux de nature differente. 



Le Call Agent 



Le Call Agent, egalement appele controleur de passerelles multimedias ou encore 
SoftSwitch, selon une terminologie non officielle mais courante, a pour fonction de 
controler les passerelles et de concentrer toute 1' intelligence ainsi que la prise de decision 
dans le reseau. 

Entite logique, pouvant etre localisee n'importe ou dans le reseau, le Call Agent est 
specifiquement responsable de l'etablissement, de la maintenance et de la terminaison 
des appels etablis entre des terminaux appartenant a des reseaux de nature differente. 

Comme ces operations sont initiees au niveau des passerelles multimedias, le Call Agent 
intervient pour controler l'activite de ces dernieres et leur donner les directives de traite- 
ment de ces operations. II est en quelque sorte le maitre d'oeuvre et d' operation des 
communications entre les reseaux. 

Dans la mesure ou il contribue a centraliser le reseau autour de lui, le Call Agent est une 
entite fortement sollicitee. De ce fait, il devient un element sensible dans le reseau, parti- 
culierement en cas de panne. Neanmoins, cette centralisation n'intervient que pour arbi- 
ter et assurer la maintenance et la gestion des echanges de signalisation. Elle n' entre pas 
en jeu dans les communications intra-reseau. En outre, pour gerer les pannes, il est plus 
simple de mettre en place des doublures, sous forme de Call Agents redondants, que de 
rendre toutes les passerelles multimedias redondantes. 

II est possible d' avoir plusieurs Call Agents, chacun ay ant en charge un pare de passerel- 
les multimedias. Par exemple, chaque operateur peut gerer ses propres passerelles par un 
Call Agent proprietaire. Le protocole MGCP ne definissant pas de mecanisme de 
synchronisation entre Call Agents, on doit considerer independamment chaque Call 
Agent et les passerelles qu'il controle. 

Fondamentalement, MGCP repose sur un modele maitre-esclave, et il n'est pas dans son 
objectif de fournir des mecanismes de communication entre les agents de controle, qui 
sont des entites de meme nature, auxquelles le modele maitre-esclave ne convient pas. 
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Pour faire communiquer entre eux plusieurs Call Agents, un protocole tel que SIP peut 
etre utilise afin de negocier les parametres de communication. 

Les passerelles multimedias 

Selon le protocole MGCP, la notion de passerelle est assez floue et couvre un vaste 
ensemble de definitions, notamment les suivantes : 

• Passerelle d'operateur telephonique, pour faire le lien entre un reseau telephonique et 
un reseau IP. Les operateurs de telephonie alternatifs, par exemple, utilisent souvent le 
reseau RTC de l'abonne comme reseau de base puis basculent les flux de l'abonne vers 
un reseau IP (lequel presente l'avantage d'etre a commutation de paquets, done sans 
reservation de ressources, et ainsi moins couteux qu'un reseau a commutation de 
circuits) sur de longues distances internationales, avant de basculer a nouveau les flux 
de 1' appelant vers le reseau RTC auquel le terminal du destinataire est connecte. 

• Passerelle residentielle de type box (boitier exploitant le modem, le cable ou les tech- 
nologies xDSL), generalement mise a disposition par le FAI. Ce boitier fait la liaison 
entre le reseau IP des utilisateurs et le reseau d'acces telephonique de l'operateur. 
Nous en verrons une illustration un peu plus loin dans ce chapitre. 

• PBX d'entreprise faisant la liaison entre le reseau IP de l'entreprise et le reseau tele- 
phonique RTC de l'operateur. Au sein de l'entreprise, des telephones IP ou des soft- 
phones peuvent etre utilises en interne pour exploiter les services complementaires 
qu'offre le reseau IP et permettre la convergence des flux sur un support unique. 
Comme le reseau de l'entreprise est connecte a une liaison RTC, une passerelle est 
toutefois necessaire. 

Par rapport aux passerelles initialement prevues dans le protocole H.323, les passerelles 
multimedias sont simplement depourvues de la fonctionnalite de traitement des appels. 
Elles s'en remettent pour cela au Call Agent. Neanmoins, elles conservent intact leur 
emplacement physique, a la frontiere entre les deux reseaux de nature distincte, alors que 
le Call Agent peut etre situe n'importe ou, comme l'illustre la figure 5.3. 

X, Y ou Z represented des reseaux quelconques (RNIS, ATM, IP, RTC, etc.). Sur chacun 
de ces reseaux, le protocole de signalisation intra-reseau de son choix peut etre utilise, 
par exemple SIP ou H.323 dans un reseau IP, ou SS7 dans un reseau RTC. MGCP ne peut 
s'appliquer au sein de ces reseaux, mais seulement a leur peripheric afin d' assurer la 
gestion et le traitement des communications interreseau. 

On observe deux niveaux de communications : l'un qui fait intervenir les reseaux et les 
passerelles multimedias et 1' autre les passerelles multimedias et le Call Agent. Le proto- 
cole MGCP s' applique exclusivement a transmettre de la signalisation entre le Call 
Agent et les passerelles. Les flux de donnees multimedias (voix, video, donnees) entre 
deux terminaux appartenant a des reseaux differents ne transitent jamais par le Call 
Agent. Une fois que le Call Agent en a donne l'autorisation, ces flux sont vehicules de 
poste terminal a poste terminal, en passant uniquement par la passerelle. 
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Figure 5.3 

U architecture MGCP 




Le role de la passerelle multimedia est done reduit a racheminement coherent des donnees, 
ce qui implique qu'elle accomplisse les taches suivantes : 

• conversion du signal ; 

• adaptation au support ; 

• compression des donnees ; 

• conversion de la signalisation ; 

• multiplexage ; 

• mise en paquets. 

Les passerelles multimedias se retrouvent ainsi reduites a leur fonctionnalite premiere et 
fondamentale de transmission : elles travaillent au niveau du media lui-meme et assurent 
le traitement des donnees, sans la logique de traitement. Toutefois, ces actions ne sont 
realisables qu'en accord avec le Call Agent, dont les passerelles sont les executants. 

Globalement, le mode de fonctionnement des passerelles est done allege par rapport a 
H.323 et le reseau devient constitue d'elements simples et conflgurables. 

Les communications MGCP passent systematiquement par le protocole UDP, choisi pour 
optimiser les delais de traitement des envois. 

S'il n'est pas mentionne, le Call Agent utilise par defaut le port 2727 pour ses communi- 
cations, tandis que les passerelles utilisent le port 2427. 
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Raisons d'etre d'un nouveau protocole 

On peut s'interroger sur la necessite d' adopter un nouveau protocole dans un contexte ou 
le protocole SIP, repute plus simple que H.323, a du mal a s'imposer compte tenu de la 
forte penetration de ce dernier. 

Cette section introduit differents aspects qui expliquent pourquoi une simple extension 
de SIP ou de H.323 n'etait pas envisageable pour jouer le role de MGCP. 

Centralisation et asymetrie 

Une extension du protocole SIP pour assurer les fonctionnalites de communication inter- 
domaine serait etrangere a la logique de fonctionnement de SIP. SIP est un protocole 
point-a-point, done decentralise. 

MGCP veut federer les communications au niveau d'une entite maitresse concentrant 
toute 1' intelligence du reseau et imposant ses directives a 1' ensemble des autres entites du 
reseau. L' architecture requise par ce modele est done celle d'un maitre et d'esclaves. 
Pour cette raison, on dit que MGCP est un protocole asymetrique. Une seule entite a la 
vision de 1' ensemble du reseau et la possibilite de 1'administrer dans sa globalite. SIP est 
symetrique, et ses echanges sont effectues sur le modele client- serveur. La vision de 
MGCP et celle de SIP sont done intrinsequement differentes. 

H.323 est beaucoup plus proche du modele centralise. Mais cette centralisation est la 
cause des lourdeurs du protocole, souvent considere pour cette raison comme non adapte 
au monde Internet. Une centralisation encore accrue, si les fonctionnalites de MGCP 
etaient portees dans H.323, ne serait guere possible. Le reseau deviendrait dependant 
d' elements architecturaux tres sollicites, riches en fonctionnalites et couteux. II serait en 
outre complexe a gerer, maintenir et entretenir. 

La vision MGCP consiste au contraire a proposer un reseau aussi simple que possible en 
reportant l'intelligence des passerelles sur un element unique, le Call Agent, seule piece 
maitresse du reseau considere dans son ensemble. Ainsi, si une passerelle tombe en 
panne, il est simple, rapide et peu onereux de la remplacer. Les equipements de type 
passerelle sont facilement rempla^ables, et la compatibilite est assuree a un niveau supe- 
rieur par le Call Agent. On est proche du modele Internet, ou le controle n'est pas effectue 
par le reseau lui-meme, mais est relegue aux extremites. 

Independance et compatibilite 

MGCP a l'avantage d'etre independant de tout autre protocole, puisqu'il est cense super- 
viser n'importe lequel d'entre eux. 

En choisissant un protocole additionnel, chaque acteur de la normalisation peut 
se concentrer sur son propre protocole en admettant la possibilite de communiquer avec 
le protocole concurrent afln de satisfaire le plus grand nombre de cas de figure possible. 

Du reste, dans un contexte ou plusieurs protocoles de signalisation existent au 
seind'un reseau, l'association de l'UIT et de 1'IETF est assez significative de la 
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volonte d'offrir un modele generique sans imposer de protocole de signalisation 
sous-jacent. 

MGCP permet de federer les signalisations. Par nature, il est done pleinement compatible 
avec SIP et H.323. Non seulement, il n'entre pas en concurrence avec ces derniers, mais 
il ne se substitue aucunement a eux, puisqu'il prend en charge la signalisation entre 
reseaux exploitant differents protocoles de signalisation, et non la signalisation au sein de 
chacun d'eux. 

Dans la version 5 du protocole H.323, les passerelles sont decomposees conformement au 
modele propose par MGCP. H.323 est ainsi parfaitement compatible avec MGCP. 

Par bien des aspects, MGCP s'inspire du modele deflni par SIP. En particulier, tous deux 
utilisent un langage textuel, decrivent leur connexion par le protocole SDP et utilisent un 
jeu de codes de reponse comparable. De nombreux specialistes estiment que MGCP et 
SIP sont complementaires et forment un choix coherent pour mettre en oeuvre une archi- 
tecture de ToIP, evin^ant par cette simple consideration 1' association de MGCP avec 
H.323, que pourtant rien n'interdit. 

Exemple d'utilisation de MGCP chez les FAI 

Les FAI proposent des offres dites Triple-Play, incluant Internet, la television et la tele- 
phonic L'abonne est connecte au reseau telephonique commute RTC. C'est ce que Ton 
appelle la boucle locale, qui relie la prise telephonique de l'abonne au local technique de 
l'operateur historique. C'est dans ce local technique que les flux reseau sont devies de 
l'operateur historique vers le FAI de l'abonne. 

Chez lui, l'abonne peut mettre en place un reseau IP domestique afin de faire communi- 
quer ses differents terminaux (ordinateur, PDA, telephone IP) et de partager une 
connexion Internet. Pour assurer la connectivity entre le reseau IP de l'abonne et le 
reseau RTC de la boucle locale, le FAI met a disposition de l'abonne une Internet Box. 
Celle-ci agit comme une passerelle entre le reseau de l'abonne et celui de l'operateur en 
transcodant les flux IP en des flux RTC, et reciproquement. 

Pour l'operateur, deux contraintes fondamentales doivent etre gerees par la mise a dispo- 
sition de ces boitiers : ces boitiers doivent etre peu couteux, puisqu'ils sont diffuses a tres 
grande echelle, et ils doivent etre configurables a distance. Par exemple, pour corriger 
une defaillance protocolaire du boitier ou aj outer des fonctionnalites complementaires, 
les boitiers doivent etre a portee de controle du FAI. 

C'est exactement le role du protocole MGCP : les passerelles sont des composants 
simples, pilotes par une entite centrale, le Call Agent. C'est la raison pour laquelle ce 
protocole est couramment utilise par les FAI fran^ais. 

Pour la fourniture du service de telephonie, les FAI doivent tenir compte des combines 
telephoniques traditionnels de leurs abonnes, qui ne sont generalement compatibles 
qu'avec le reseau RTC. Cela implique une convergence des reseaux RTC et IP au niveau 
local a l'abonne. 
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La figure 5.4 illustre ce fonctionnement dans une architecture considerablement simpli- 
fiee par rapport a la realite. Le Call Agent controle toutes les passerelles. A ce titre, il est 
distinct de tous les reseaux. Dans la pratique, il est situe chez l'operateur. Le reseau RTC 
n'est que la porte d' entree vers le reseau Internet. Le FAI doit mettre en place de nouvelles 
passerelles depuis ce reseau RTC d'ou proviennent les flux des terminaux des abonnees 
vers le reseau Internet. 



Figure 5.4 

MGCP chez 
les FAI 




Un boitier d'operateur n'est autorise a emettre ou recevoir un appel qu'apres en avoir fait 
la demande aupres du Call Agent. Celui-ci peut controler les appels et generalement 
mettre en place parallelement un systeme de facturation, ainsi que des mecanismes de 
securite associes a 1' appel. 



Avantages et inconvenients de MGCP 

Comme indique precedemment, les avantages du protocole MGCP sont doubles : le 
reseau peut etre configure de maniere centralisee, et les passerelles multimedias sont des 
elements simples. 

Le Call Agent a un role central de gestion des passerelles multimedias. II offre ainsi le 
moyen de mettre a jour des fonctionnalites sur les passerelles, sans avoir besoin d'inter- 
venir sur chacune d'elles. Le reseau devient ainsi facilement administrable a distance. 
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La creation de nouveaux services est simplifiee, puisque leur implementation et leur 
gestion sont automatiquement propagees. A l'inverse, le Call Agent peut imposer un trai- 
tement personnalise selon des configurations parametrables qui supportent le nomadisme 
des utilisateurs. Par exemple, un utilisateur peut avoir la possibilite de personnaliser sa 
sonnerie d'appel dans une base de donnees cliente, a laquelle accede le Call Agent. Lors- 
que 1' utilisateur se deplace et se connecte sur un autre reseau, le Call Agent peut detecter 
les preferences de l'utilisateur dans la base de donnees, de fa^on a lui conserver la sonnerie 
qu'il avait configuree. 

Dans la mesure ou elles n'assument pas la logique de controle des appels, mais seulement 
les traitements de bas niveau, les passerelles sont des entites relativement simples et peu 
couteuses. Si l'une d'elles tombe en panne, il est facile de la remplacer car il n'est pas neces- 
saire de reprogrammer toutes les configurations de la passerelle decrivant son etat avant la 
panne : c'est le Call Agent qui se charge de configurer dynamiquement la passerelle. 

Inconvenients 

MGCP propose une architecture centralisee chargee du controle dans le reseau. Par 
consequent, le reseau est dependant de cette entite centrale, qui constitue un point de 
vulnerabilite. 

En cas de dysfonctionnement de ce serveur, le reseau tout entier devient defaillant puis- 
que aucun controle ne peut plus y etre effectue. Neanmoins, le protocole MGCP a prevu 
des procedures pour que, en cas de panne, une passerelle puisse basculer d'un controleur 
vers un autre. 

Un autre inconvenient de MGCP est qu'il impose globalement une plus grande quantite 
de messages de signalisation. Les terminaux qui l'implementent ne se connectent jamais 
directement entre eux, mais doivent imperativement au prealable en demander l'auto- 
risation au centre de controle. 

Ce mode de fonctionnement se distingue nettement de ceux des protocoles H.323 et SIP, 
qui permettent aux terminaux de communiquer entre eux sans faire intervenir d' entite 
tierce. Globalement, les protocoles H.323 et SIP assurent le controle des appels eux- 
memes, tandis que le protocole MGCP assure le controle des entites du reseau. 



Principes cTetablissement d'une communication 

On appelle endpoint un equipement dit de terminaison, qui represente soit la source soit 
la destination d'un message multimedia. 

Un routeur reseau n'est pas un endpoint puisqu'il se contente d'acheminer des donnees, 
sans etre a l'origine de l'envoi. Le Call Agent n'est pas non plus un endpoint, puisqu'il ne 
traite pas des messages multimedias. 

Des lors qu'une entite participe aux echanges de medias et se place comme source ou 
destinataire de ces echanges, meme si elle n'est pas la source initiale ou le destinataire 
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final et qu'elle ne joue qu'un role d'intermediaire dans ces echanges, elle est consideree 
comme un endpoint. Les terminaux des utilisateurs sont des endpoints de reference. 

Supposons que nous souhaitions connecter deux terminaux, appeles des endpoints. 
Chacun d'eux se trouve localise derriere une passerelle multimedia. Ces deux passerelles 
sont elles-memes controlees par un Call Agent, comme l'illustre la figure 5.5. 



Figure 5.5 

Mise en relation 
de deux endpoints 
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Passerelle 
Multimedia 
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Multimedia 
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Enpoint_2 



Pour mettre en relation les deux endpoints, les cinq etapes suivantes sont necessaires : 

1. Requete de creation de connexion vers la premiere passerelle. Le Call Agent sollicite 
la creation d'une connexion avec un endpoint aupres de la passerelle concernee. 

2. Reponse de la premiere passerelle. Celle-ci se charge de joindre le endpoint et lui 
attribue les ressources necessaires a la communication : une session est creee entre la 
passerelle et le endpoint. En retour, la passerelle envoie au Call Agent un descriptif 
de la session creee. Ce descriptif contient 1' ensemble des parametres permettant de 
joindre le endpoint, incluant l'adresse IP de ce dernier, le port UDP sur lequel la 
communication est en attente et les codecs supportes. 

3. Requete de creation de connexion vers la seconde passerelle. Le Call Agent procede 
de la meme fa^on pour le second endpoint et sa passerelle : il sollicite cette derniere 
en lui envoy ant un message pour la creation d'une connexion avec le second endpoint. 
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En plus, et dans le meme message, le Call Agent lui fait parvenir le descriptif de session 
que lui a retourne la premiere passerelle. 

4. Reponse de la seconde passerelle. La seconde passerelle joint le endpoint concerne et 
alloue les ressources necessaires a cette communication. En retour, elle transmet au 
Call Agent un descriptif de session contenant les parametres permettant de joindre le 
second endpoint. 

5. Mise en relation des deux endpoints. Le Call Agent contacte la premiere passerelle et 
lui transmet le descriptif de la session retournee par la seconde passerelle. Comme 
une connexion existe deja avec le endpoint, il n'est pas necessaire de creer une nou- 
velle connexion. II suffit de modifier celle qui existe et de la completer. C'est done 
une commande de modification qui est effectuee par le Call Agent. 

Une fois ces etapes achevees, la communication debute dans les deux sens. Elle peut etre 
modifiee a tout moment par le Call Agent, qui peut imposer, par exemple, un changement 
de codec, d'adresse IP ou de port. De meme, le Call Agent peut mettre fin a la communi- 
cation a tout moment en envoyant un message aux passerelles, qui doivent alors rompre 
les connexions. 

On peut resumer tous les etats possibles d'une passerelle multimedia comme illustre a la 
figure 5.6. 



Figure 5.6 
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Les messages MGCP 

La communication avec MGCP obeit a un modele de type client- serveur. Un message 
MGCP est soit une requete, soit une reponse a une requete. II est constitue sous forme 
textuelle, ce qui simplifle son usage (traitement sans compilateur, done plus rapide, et 
debogage immediat), et presente plusieurs analogies avec le protocole SIP. Ainsi, une 
transaction MGCP est-elle constitute d'une requete et de la reponse a cette requete, 
eventuellement precedee de reponses temporaires. 

Le format d'un message MGCP est illustre a la figure 5.7. 



Figure 5.7 

Format d'un message MGCP 
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Corps du message 



Dans ce message, on distingue trois parties : 

• Ligne de requete ou de reponse : notifle la commande a executer (s'il s'agit d'une 
requete) ou le resultat de la commande (s'il s'agit d'une reponse). C'est une partie 
indispensable. 

• En-tete : specifle la liste des parametres du message. C'est une partie facultative. 

• Corps du message : decrit les parametres de la session a etablir. C'est une partie 
facultative. 

Plusieurs lignes peuvent constituer chacune des parties. On separe chaque ligne par des 
retours chariot, ou CR (Carriage Return), et des sauts de ligne, ou LF (Line Feed), ou par 
des retours chariot seulement. 

Notons que, dans la RFC 3435, la partie speciflant la ligne de requete ou de reponse et 
celle speciflant l'en-tete sont regroupees. 

Adressage des endpoints 

L'adressage d'un endpoint est represents dans un format semblable a 1' e-mail, dans le 
respect de la RFC 821. 

Sa syntaxe est la suivante : 



endpoint @domaine[: port] 
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La partie domaine specifie le nom de domaine absolu, conformement a la RFC 1034 
(DNS), incluant le nom de la passerelle permettant d'acceder au domaine. Par exemple, 
un nom de domaine peut etre : 

majpasserelle. mon_domaine.fr 

Le nom de domaine peut aussi etre specifie par une adresse MAC ou une adresse IP, au 
format IPv4 ou IPv6, a condition de l'indiquer entre crochets. 

La partie endpoint specifie le nom de l'entite consideree. Elle est deflnie selon trois 
niveaux hierarchiques separes par le symbole /, de la fa^on suivante : 

niveau _hierachique_l/niveau_hierachique_2/niveau_hierachique_3 

La hierarchisation est de plus en plus speciflque au fur et mesure qu'on se deplace vers la 
droite du nom du endpoint. Ainsi, le niveau_hierachique_3 est plus precis que le 
niveau_hierachique_2, lui-meme plus precis que le niveau_hierachique_l . 

Les parties endpoint et domaine peuvent etre formees de n'importe quel caractere en 
dehors des symboles espace, arobase et slash, qui font deja office de separateurs. 

Les symboles de multiplication (*) et dollar ($) sont egalement interdits dans les parties 
endpoint et domaine, car ils possedent une signification particuliere. Le symbole de 
multiplication peut remplacer n'importe quelle autre chame constitute d'un ou de 
plusieurs caracteres, tandis que le caractere dollar peut remplacer une et une seule lettre. 
Ce sont des caracteres couramment utilises avec cette signification dans les langages de 
programmation informatique. De cette maniere, il est possible d'adresser plusieurs 
composants differents en meme temps. Les parties endpoint et domaine peuvent avoir 
plus de 255 caracteres. La specification du port est facultative. 

L'adressage d'un Call Agent est comparable a celui des endpoints. II respecte la syntaxe 
suivante : 

callagent@ domaine [: port] 

Les restrictions de nommage des parties callagent et domaine sont semblables a celles 
concernant les endpoints. 

Exemples de noms d'endpoint et de Call Agent 

D'une maniere generate, les noms des endpoints et des Call Agents peuvent etre librement 
choisis en respectant les contraintes precedemment mentionnees. 

L'appendice E de la RFC 3435 specifie des conventions de nommage, dont nous donnons 
ci-dessous quelques exemples. 

Pour adresser la ligne telephonique analogique d'un terminal (par exemple ligne 
numero 1), on utilise typiquement le nom suivant : 

aaln/1 @ majpasserelle. mon_domaine 

ou aaln designe la ligne analogique d'un endpoint (analog access line endpoint). 
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Si Ton considere une seconde ligne telephonique de terminal, on utilise le nom suivant : 

aaln/2 @ rna_passerelle. mon_domaine 

Si Ton souhaite envoy er un message s'afflchant sur l'ecran de la premiere ligne tele- 
phonique consideree, le message est adresse de la fa^on suivante : 

disp/aaln/1 @ ma_passerelle. mon_domaine 

ou disp designe l'afflchage (display). 

Pour un Call Agent, on utilise : 

Mon_Call_Agent@Call_Agent.mon_domaine 

Le fait que ce nom soit generique est tres pratique pour localiser le Call Agent de fa^on 
independante. Par exemple, si le Call Agent est deplace dans un autre reseau, les passe- 
relles n'ont pas besoin d'etre mises a jour. 

Identifiant de transaction 

Pour correler une requete avec sa ou ses reponses, le protocole MGCP utilise un code 
appele identifiant de transaction. De cette maniere, une entite dispose de la possibilite 
d'emettre plusieurs requetes successivement, sans en avoir re^u les reponses. U entite 
peut determiner a quelle requete fait reference une reponse en analysant la valeur de 
1'identiflant de transaction. 

L' identifiant de transaction permet en outre a une entite (une passerelle ou le Call Agent) 
de reperer des eventuelles duplications de message. 

II existe deux possibilites qu'un message soit duplique : 

• Pour une passerelle, il y a duplication entre deux messages re^us si les deux messages 
comportent le meme identifiant de transaction. 

• Pour un Call Agent, il y a duplication entre deux messages re^us si les deux messages 
comportent a la fois le meme identifiant de transaction et le meme nom de passerelle a 
Torigine du message. 

On retiendra que les passerelles ne se concertant aucunement avant d' envoy er un 
message au Call Agent, elles peuvent utiliser un meme identifiant de connexion entre 
elles. Ce n'est done pas un critere discriminant au niveau du Call Agent. Par contre, pour 
chacune de ces requetes emises, le Call Agent fait varier ses identifiants de transaction, 
independamment de la passerelle qui receptionne le message. 

L' identifiant de transaction correspond a un nombre strictement compris entre et un 
million (ces deux valeurs n'etant pas incluses). Comme ces valeurs sont limitees, les 
identifiants peuvent etre reutilises, mais au minimum trois minutes apres 1' utilisation de 
ce code. 
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Parametres generaux pour les requetes et les reponses 

Les en-tetes et corps d'un message sont communs a tous les messages MGCP. 

En-tete d'un message 

Cette partie est, selon les messages, obligatoire, optionnelle ou interdite. Elle mentionne 
des attributs caracterisant le message. 

Le format general d'un parametre d' en-tete respecte le modele suivant : 

nomjparametre:valeurjparametre 

Le nom du parametre est forme d'un ou de deux caracteres (lettre ou chiffre). Le 
tableau 5.1 fournit la liste de tous les parametres possibles. 

Tableau 5.1 - Parametres d'en-tete d'un message MGCP 

Description 

Definit des informations sur le codage des donnees envoyees ou regues. Le seul attribut 
defini pour ce parametre est I'encodage, represents par le caractere e et dont la valeur 
peut etre soit A, soit mu. On trouve done couramment la valeur B:e:mu. D'autres attributs 
peuvent etendre ce parametre. 

Identifiant d'appel. C'est une chaine de caracteres hexadecimaux, comportant au plus 
32 caracteres. Par exemple C:1234567abc. 

Liste les capacites du endpoint (incluant les paquetages, les modes de connexion et even- 
tuellement les extensions supportes). Cela inclut notamment les elements suivants : 

- liste des codecs supportes ; 

- liste des reseaux supportes ; 

- duree de mise en paquet ; 

- bande passante necessaire ; 

- suppression d'echo (supportee ou non) ; 

- suppression des silences (supportee ou non) ; 

- reservation de ressources (supportee ou non) ; 

- securite (cryptage du media ou non) ; 

- liste des paquetages supportes ; 

- liste des modes de connexion supportes. 

Liste les identifiants de connexion pour toutes les connexions existantes sur le endpoint. 

Liste les modes de connexion supportes par le endpoint. On distingue les modes sui- 
vants : 

- sendonly : emission de paquet seulement ; 

- recvonly : reception de paquet seulement ; 

- sendrecv : emission et reception de paquet ; 

- confrnce : conference avec plusieurs intervenants ; 

- inactive : communication inactive ; 

- loopback : bouclage ; 

- conttest : test de continuity ; 

- netwloop : bouclage du reseau ; 

- netwtest : test de continuity du reseau. 



Parametre 


Code 


BearerInformation 


B 


Call- Id 


C 


Capabilities 


A 



Connections 
ConnectionMode 



/ 
M 
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Tableau 5.1 - Parametres d'en-tete d'un message MGCP (suite) 



Parametre 


Code 


ConnectionParameters 


p 


DetectEvents 


T 


DigitMap 


D 


EventStates 


ES 


LocalConnectionOptions 


L 



MaxMGCPDatagram 

NotifiedEntity 

ObservedEvents 

PackageList 

QuarantineHandling 
ReasonCode 

RequestedEvents 

RequestedInfo 
RequestIdentifier 

ResponseAck 



MD 

N 

PL 

Q 

E 



F 
X 



Description 

Liste les parametres de connexion supportes par le endpoint. 

Liste I'ensemble des evenements qui doivent etre detectes. 

Mentionne le plan de numerotation utilise par le endpoint. Ce parametre est vide si le end- 
point n'a pas de plan de numerotation. 

Indique les etats pour lesquels un evenement est controlable. 

Liste les options utilisees par le endpoint local, incluant le type de codec utilise, le type de 
reseau (LOCAL pour un reseau local, //Wpour Internet, etc.), le debit, la qualite de service, 
le type de cryptage des flux, etc. 

Indique la taille maximale d'un datagramme MGCP qui peut etre supporte par le endpoint 
(excluant les couches inferieures a MGCP). Le support de ce parametre est optionnel. 
L unite est I'octet. 

Indique Tentite notifiee sur le endpoint. 

Liste les evenements observes par le endpoint. 

Liste les paquetages supportes (avec le numero de version du paquetage) par le endpoint. 
Le support de ce parametre est optionnel. 

Liste les evenements qui doivent etre ignores temporairement. 

Indique la valeur du dernier message de code de retour expliquant le traitement de la 
requete retourne par le Call Agent vers une passerelle avec les commandes RestartInPro- 
gress ou DeleteConnection. Retourne la valeur 000 si I'etat du endpoint est normal. 

Liste un ensemble d'evenements surveilles, avec Taction (ou les actions) a entreprendre lors- 
que Tevenement survient (si aucune action n'est mentionnee, Taction par defaut est activee). 

Liste toutes les donnees qui sont sollicitees. 

Retourne I'identifiant de requete de la derniere commande NotificationRequest regue. 
Si aucune requete de ce type n'a ete regue, la valeur est retournee. 

Liste les identifiants de toutes les transactions qui ont ete validees. Une plage d'identi- 
fiants peut etre mentionnee avec le symbole de tiret, par exemple K:1 231 5-1 2350, 12355, 
12399. Dans ce cas, les transactions d'identifiants 12315 a 12350, ainsi que 12355 et 
72399 sont acquittees. 



RestartDelay 


RD 


Indique le delai (en seconde) avant redemarrage. 


RestartMethod 


RM 


Indique le redemarrage du endpoint (apres le delai specifie dans le parametre Restar- 
tDelay). 


SecondConnectionId 


12 


Identifiant de la connexion 


SecondEndpointId 


Z2 


Identifiant du endpoint 


SignalRequests 


s 


Liste tous les signaux actifs. 


SpecificEndPointId 


z 


Identifiant (au format respectant la RFC 821) compose d'une chaine de caracteres arbi- 
trage, suivi, apres une arobase, du nom de domaine de la passerelle a laquelle le end- 
point est associe. 


RemoteConnection- 
Descriptor 


RC 


Description de la session distante 


LocalConnection- 
Descriptor 


LC 


Description de la session locale 
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Corps d'un message 

Cette partie est, selon les messages, obligatoire, optionnelle ou interdite. Elle mentionne 
des attributs relatifs a la communication sollicitee. Elle est implementee en utilisant le 
protocole SDP, introduit au chapitre precedent dedie a SIP. 



La ligne d'etat MGCP 

La ligne d'etat est constitute des quatre elements suivants, illustres a la figure 5.8 : 

• Requete : indique Taction qui va etre entreprise par ce message. 

• Identiflant : tel qu'il a ete presente precedemment. 

• Destination : specifle l'adresse de la ou des destinations concernees par le message. 

• Version : indique la version du protocole MGCP utilisee. 



Figure 5.8 

Detail de la ligne 
d'etat MGCP 




Les requetes 

Le protocole MGCP definit neuf requetes permettant de specifier Taction a entreprendre. 

Les commandes sont lancees entre le Call Agent et les passerelles (Media Gateway). 
Comme MGCP est un protocole de type maitre-esclave, toutes les entites n'ont pas des 
possibilites comparables, et ces commandes ne peuvent etre lancees qu'a Tinitiative de 
Tune de ces entites, soit le Call Agent, soit la Media Gateway. 

On distingue done deux categories de commandes : celles qui sont lancees par le Call 
Agent vers une ou plusieurs passerelles et celles qui vont dans T autre sens, de la passe- 
relle vers le Call Agent. 

A chaque requete correspond un code en quatre lettres de caracteres ASCII, qui permet 
de condenser la taille de la requete. Les neuf requetes et leur code respectif sont recapitu- 
les au tableau 5.2. 

Le protocole MGCP etant extensible, d'autres requetes pourront venir Tenrichir dans les 
prochaines versions. 

Nous decrivons brievement ci-apres ces neuf requetes fondamentales. 
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Tableau 5.2 - Format des neuf requetes MGCP 



Format complet 


Format abrege 


AuditConnection 


AUCX 


AuditEndpoint 


AUEP 


CreateConnection 


CRCX 


DeleteConnection 


DLCX 


EndpointConfiguration 


EPCF 


ModifyConnection 


MDCX 


NotificationRequest 


RQNT 


Notify 


NTFY 


RestartInProgress 


RSIP 



Du Call Agent vers les passerelles 

Le Call Agent peut agir sur les passerelles dont il a le controle par 1' intermediate de sept 
commandes. 

CreateConnection 

Cette commande permet de creer une connexion sur un endpoint a travers une passerelle. 
L' option LocalConnectionOptions permet de deflnir une QoS. 

Pour l'etablissement et la liberation des connexions, MGCP se sert de signaux et 
d'evenements. 

La figure 5.9 presente un scenario de creation d'une connexion MGCP entre deux 
entites. 



Figure 5.9 

Creation d'une connexion 





Call Agent 




Passerelle 
multimedia 



CreateConnecti 



ion 



200 OK 



ModifyConnection 

Cette commande permet de modifier les parametres associes a une connexion deja 
etablie. 



Par exemple, il est possible de modifier le codec utilise ou le temps de paquetisation. 
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DeleteConnection 

Cette commande demande la terminaison d'une connexion etablie. 

Notification Request 

Cette commande demande a une passerelle de surveiller des evenements particuliers 
concernant un terminal. Par exemple, le Call Agent peut demander d'etre prevenu 
lorsqu'un terminal repond a un appel ou lorsque sa ligne est libre ou qu'elle devient 
occupee ou encore lorsque la tonalite d'un fax retentit sur un poste. 

De cette maniere, le Call Agent donne des directives de controle sur lesquelles il est 
susceptible d'intervenir. Par defaut, la passerelle n'a pas a alerter le Call Agent de tous 
les evenements qu'elle detecte. Elle se contente de remonter les evenements demandes. 

Une requete de notification d' evenements se presente generalement sous la forme 
suivante : 

Si evenement(s) 

Alors action(s) 

Cela revient a agir suivant les actions speciflees lorsque les evenements indiques survien- 
nent. Une action peut etre reduite a la seule indication de l'evenement, mais peut aussi 
imposer que cet evenement soit ignore ou qu'il provoque une modification de codec, par 
exemple. 

AuditEndpoint 

Cette commande demande la detection d' informations concernant un terminal. 

Par exemple, un Call Agent peut sollicker une passerelle en charge d'un terminal pour 
savoir si le terminal est present dans le reseau ou non, s'il a une communication en cours 
ou s'il est disponible, ou pour connaitre les capacites du terminal (quels codecs et debit il 
peut supporter notamment) et la sonnerie qu'il utilise. 

Toutes ces informations sont determinees par la passerelle, generalement en utilisant le 
protocole SNMP (Simple Network Management Protocol). 

AuditConnection 

Cette commande demande la detection de parametres concernant une connexion. 

Par exemple, un Call Agent peut sollicker une passerelle en charge d'un terminal pour 
savoir si une connexion existe ou non et connaitre les types de flux (voix, videos, 
donnees), codecs et protocoles utilises dans la communication. 

EndpointConfiguration 

Cette commande est utilisee pour la configuration du type de codage des flux qui sont 
re^us par un terminal telephonique sur le lien telephonique tradkionnel (c'est-a-dire le 
lien circuit, et non IP). 
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D'une passerelle vers le Call Agent 

Une passerelle dispose de trois commandes pour communiquer avec le Call Agent, dont 
Tune est similaire a celle qu'utilise le Call Agent. 

DeleteConnection 

En principe, c'est le Call Agent qui doit indiquer la terminaison d'un appel et non 
l'inverse. Nous avons presente cette commande precedemment dans ce cadre. 

Dans certains cas, la passerelle peut rencontrer des problemes techniques qui l'empe- 
chent de maintenir la communication et la contraignent a achever la connexion. Cette 
commande permet d'indiquer au Call Agent qu'un evenement non prevu a interrompu la 
connexion. 

Notify 

Cette requete fait suite a une requete rqnt envoyee par le Call Agent. Elle indique que 
1' evenement pour lequel le Call Agent avait sollicite une alerte est survenu. 

RestartlnProgress 

La passerelle peut avertir le Call Agent de l'indisponibilite d'un ou de plusieurs terminaux 
d'extremite au moyen de cette commande. 

Le Call Agent peut decider de tester les terminaux et de les mettre hors service. 

Destination 

La destination est specifiee selon le format d'adressage que nous detaillons plus loin dans 
ce chapitre. 

Version 

L' indication d'une version permet de s' assurer de la compatibility entre les entites 
communicantes. 

Le recepteur peut interpreter le message s'il utilise la meme version du protocole MGCP. 
Pour specifier la version du protocole MGCP dans un message de requete, le mot-cle 
MGCP doit preceder le numero de version avec une espace comme separateur. Par exem- 
ple, pour la version 1.0 actuellement utilisee, on indique MGCP 1.0. 

Optionnellement, il est possible d'ajouter a la suite une nouvelle espace suivie d'un 
message textuel representant un profll. Le profll est utile afm de distinguer differentes 
categories d'utilisateurs et de leur accorder des droits et des restrictions particulieres. 

En recevant ce message, le recepteur doit adapter son comportement selon le profll 
renseigne. Notamment, on peut imaginer que 1' appel soit interdit sur certains profils ou 
necessite une authentiflcation particuliere. 
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Un message de requete complet serait de la forme suivante : 

CRCX 1204 aalnl l@ma_passerelle.mon_domaine.fr MGCP 1.0 



C: A3C47F21456789F0 
L: p:10, a:PCMU 
M: recvonly 



Les reponses MGCP 

Toutes les requetes MGCP sont acquittees par un message de reponse. 
Le format de ces messages de reponse est illustre a la figure 5.10. 



Figure 5.10 

Format des reponses 



Corps 



Code reponse 



Comment a in 



Comme pour SIP, les messages de reponse a une requete sont envoyes par un code de 
retour a trois chiffres. La aussi, on distingue plusieurs categories de codes de retour, 
assez comparables a ceux de SIP. 

Le premier chiffre d'un code de retour designe la categorie de code de retour a laquelle le 
code appartient. Le tableau 5.3 indique quelques codes d'etat qui ont ete dermis et les 
categories auxquelles ils appartiennent. 

Tableau 5.3 - Principaux codes d'etat des reponses MGCP 

Code d'etat Commentaire 



Oxx - Messages d'acquittement 
La requete a bien ete regue. 



000 



Reponse d'acquittement (indique seulement la reception de la requete). 



1xx - Message d'information 

C'est une reponse temporaire, qui informe I'emetteur. Une reponse definitive sera emise plus tard. 



100 

101 



La requete est en cours de traitement. 

La requete est en attente. Elle sera traitee des que les requetes qui la precedent auront ete execu- 
tes. 



Theorie de la TolP 



Parte I 



Tableau 5.3 - Principaux codes d'etat des reponses MGCP (suite) 

Code d'etat Commentaire 

2xx - Message de succes 

La requete a ete regue, comprise et acceptee par le serveur. 

200 Requete executee avec succes. N'importe quelle requete peut etre validee par ce code de retour. 

250 La requete DeleteConnection a ete executee avec succes (autrement dit, la connexion a bien ete 

supprimee). 

4xx - Message signalant une erreur temporaire 

La meme requete pourra eventuellement etre envoyee plus tard. 

400 Erreur temporaire qui n'est pas precisee. 

401 Le telephone est decroche. 

402 Le telephone est raccroche. 

403 Les ressources sont insuffisantes pour traiter la requete. 

404 La bande passante est insuffisante pour satisfaire la requete. 

405 L'equipement est en train de redemarrer. 

406 Depassement de delai : la requete n'a pu etre executee dans des delais raisonnables de traite- 
ment. 

407 La requete a ete annulee par un evenement externe (par exemple, une requete DeleteConnection 
peut interrompre une requete ModifyConnection). 

409 Le endpoint est surcharge pour le moment. 

410 Aucune entite n'est disponible pour prendre en charge la requete. 

5xx - Message signalant une erreur permanente 
Cette requete ne sera jamais prise en charge. 

500 Le endpoint n'est pas reconnu. 

501 Le endpoint n'est pas pret (eventuellement il ne fonctionne pas). 

502 Les ressources du endpoint ne lui permettent pas de prendre en charge la requete. 

503 L'asterisque (utilise pour I'adressage des endpoints) est trop complique. 

504 La commande n'est pas reconnue ou n'est pas supportee. 

505 Le parametre RemoteConnexionDescriptor n'est pas supporte. Cette reponse devrait etre 
declenchee lorsqu'un champ du descripteur RemoteConnexionDescriptor n'est pas supporte. 

506 Impossible de satisfaire les parametres LocalConnectionOptions et RemoteConnectionDescrip- 
tor en meme temps. En principe, cette reponse est declenchee lorsque des champs de ces para- 
metres presentent un conflit. 

507 Une fonctionnalite non specif ique n'est pas supportee. Cette reponse n'est pas recommandee, car 
trop generale. 

508 La liste des evenements que la requete demande d'ignorer (quarantine handling) est inconnue ou 
n'est pas supportee. 
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Tableau 5.3 - Principaux codes d'etat des reponses MGCP (suite) 

Code d'etat Commentaire 

509 Le parametre RemoteConnexionDescriptor presente une erreur. Cette reponse devrait etre 

declenchee lorsqu'un champ du descripteur RemoteConnexionDescriptor presente une erreur 
syntaxique ou semantique. 



510 Une erreur protocolaire non specifique a ete detectee. Cette erreur ne doit etre utilisee qu'en der- 
nier recours, car elle est trop generale. 

51 1 La commande comporte une extension qui n'a pu etre reconnue. 

512 La passerelle n'est pas capable de detecter Tun des evenements que la requete sollicite. 

513 La passerelle n'est pas capable de generer I'un des signaux que la requete sollicite. 

514 La passerelle n'est pas capable d'envoyer I'annonce que la requete sollicite. 

515 Le Connection-Id est incorrect (ne fait pas reference a une valeur referenced) 

516 Le Call-Id est incorrect (c'est-a-dire que le Connection-Id n'est pas associe a ce Call-Id) ou bien il 
est inconnu. 

517 Le mode utilise est incorrect ou non supporte. 

518 Le paquetage n'est pas supporte ou est inconnu. La liste des paquetages disponibles est genera- 
lement specifiee dans le message. 

519 Le endpoint n'a pas de plan de numerotation. 

520 Le endpoint est en train de redemarrer. L'erreur 405 est preferable si le redemarrage n'est pas per- 
sistant, ce qui est le plus souvent le cas. Ce code est surtout mentionne pour assurer la compati- 
bility entre les versions. 

521 Le endpoint est redirige vers un autre Call Agent. 

522 L'evenement ou le signal mentionne dans la requete n'existe pas. 

523 L'action demandee est inconnue ou la combinaison d'actions n'est pas permise. 

524 Le parametre LocalConnectionOptions comporte des champs contradictoires. 

525 Le parametre LocalConnectionOptions comporte une extension inconnue. 

526 La bande passante n'est pas suffisante. Indique en principe, un manque de bande passante tem- 
poraire. Si la bande passante demandee est trop importante a obtenir sur la ligne considered, une 
erreur 404 est preferable. 

527 Le parametre RemoteConnectionDescriptor n'a pas ete specifie. 

528 La version du protocole MGCP utilisee dans la requete est incompatible. 

529 Une erreur materielle interne a ete detectee. 

530 Erreur avec un protocole de signalisation CAS. 

531 Erreur sur un ensemble de faisceaux. 

532 Le parametre LocalConnectionOptions contient des valeurs qui ne sont pas supportees. 

533 La reponse est trop longue. 

534 Echec lors de la negociation de codec. 
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Tableau 5.3 - Principaux codes d'etat des reponses MGCP (suite) 

Code d'etat Commentaire 

535 La periode de paquetisation est incorrecte. 

536 La methode RestartMethod n'est pas supportee ou est inconnue. 

537 Lextension du plan de numerotation est inconnue ou n'est pas supportee. 

538 Un parametre de signal ou d'evenement est incorrect (inconn u, non supporte, errone ou manquant 
dans la requete). 

539 Un parametre de commande est invalide ou n'est pas supporte. 

540 La limite du nombre de connexion par endpoint a ete depassee. 

541 Le parametre LocalConnectionOptions est invalide ou n'est pas supporte. 

Les codes de retour numerates de 800 a 899 et 903 a 905 inclus sont reserves pour les 
paquetages. 

Les codes de messages non dermis sont interpretes selon la correspondance etablie au 
tableau 5.4. 

Tableau 5.4 - Interpretation des codes d'erreur inconnus 



Code d'erreur inconnu commencant par le chiffre 


Interprets comme s'il 


s'agissait du code 







000 




1 




100 




2 




200 




3 




521 




4 




400 




5,6, 7,8 ou 9 




510 




Un message 


de reponse complet serait de la forme suivante : 





200 1204 OK 



I: FDE234C8 

v=0 

o=- 25678 753849 IN IP4 128.96.41.1 

s=- 

c=IN IP4 128.96.41.1 

t=0 

m=audio 3456 RTP/AVP 96 

a=rtpmap:96 G726-32/8000 
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Conclusion 



Comme il se place en parallele des protocoles de signalisation interieurs des reseaux, 
MGCP ne souffre pas vraiment de concurrence. II est du reste le protocole de reference 
pour les fournisseurs d'acces a Internet, qui l'utilisent afln de controler les equipements 
qu'ils mettent a disposition des utilisateurs. 

Tandis que l'avenir des protocoles H.323 et SIP semble se profiler avec la specification 
d'un protocole de nouvelle generation, H.325, con^u par l'UIT pour simplifler notam- 
ment la gestion des equipements de controle, de la qualite de service et du passage par les 
pare-feu d'entreprise, l'avenir de MGCP semble quant a lui serein. 

Son successeur annonce MeGaCo existe depuis l'annee 2000, sans veritablement susciter 
d'interet chez les equipementiers ni manifester de veritables innovations qui justifieraient 
un changement de protocole. 



6 



La qualite de service 



Comme explique en debut d'ouvrage, pour transporter de la parole telephonique, il faut 
que le temps de transport de bout en bout soit limite puisque nous avons affaire a une 
application avec interaction humaine. Cette limitation est d'une centaine de millisecondes 
pour obtenir une tres bonne qualite et jusqu'a 300 ms pour une conversation passant par 
un satellite geostationnaire. 

Pour obtenir ces temps de reponse, il faut que le reseau offre une qualite de service. 
Plusieurs solutions peuvent etre mises en oeuvre pour cela selon deux grandes directions : 
un controle effectue au niveau applicatif et un controle effectue au niveau reseau. 

Dans le premier cas, l'application s'adapte au reseau. Si le reseau est charge, l'adaptation 
s'effectue en diminuant le debit du flux. Dans le second cas, c'est le reseau qui s'adapte a 
l'application. II faut en ce cas demander au reseau un SLA (Service Level Agreement), qui, 
compte tenu du debit et des contraintes temporelles, assure la qualite de service demandee. 

Nous examinons dans ce chapitre plusieurs propositions appartenant a l'une ou 1' autre de 
ces solutions. Dans la premiere, nous nous pencherons sur RTP/RTCP et dans la seconde 
sur IntServ, DiffServ et MPLS/GMPLS. Avant cela, nous expliquerons pourquoi les 
protocoles de transport TCP et UDP sont peu qualifies pour assurer ces fonctions. 

Le controle et les protocoles de transport 

Avec quel protocole transporter les flux de ToIP et plus generalement tous les flux 
multimedias, soumis a des contraintes temporelles particulierement fortes dans les reseaux 
IP? 

Le protocole TCP exige de nombreuses procedures de controle, qui le rendent peu adapte 
au transport des donnees multimedias avec de fortes contraintes de delai. 
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A 1' inverse, le protocole UDP ne propose aucun mecanisme de controle, ce qui ne le 
qualifle guere pour le traitement des donnees multimedias. 

TCP et le transport de donnees multimedias temps reel 

Le protocole TCP implemente plusieurs mecanismes de controle : 

• Controle de sequence. Chaque trame est numerotee au niveau de l'emetteur. Cela permet 
de reconstituer l'ordre des trames au niveau du recepteur, grace a 1'estampille sequentielle. 

• Controle de flux. Un mecanisme de fenetrage limite le nombre de paquets qu'il est 
possible d'emettre. 

• Controle d'erreur. Le recepteur envoie un message d'acquittement pour toutes les 
trames regues. II peut exister des acquittements cumulatifs, permettant d'acquitter 
plusieurs trames en meme temps. Dans le cas ou le recepteur re^oit des trames qui ne 
sont pas integres, par exemple si une erreur est detectee lors du controle de redon- 
dance, il ne les acquitte pas. Si certaines trames de l'emetteur ne re^oivent pas 
d'acquittement passe un certain delai, appele temporisateur de reemission, l'emetteur 
considere que ces trames sont perdues dans le reseau (un routeur sature detruit les 
paquets qui arrivent en surplus) ou que le recepteur ne les a pas revues de fa^on 
correcte. II entreprend alors de retransmettre toutes les trames qui n'ont pas ete acquit- 
tees. De cette fa^on, l'integralite des trames est necessairement regue, et la fiabilite des 
echanges comme l'integrite des donnees sont garanties. 

• Controle de congestion. Des mecanismes (appeles Slow Start et Congestion Avoi- 
dance) sont utilises pour augmenter progressivement le debit d' envoi des donnees au 
niveau de l'emetteur. Le debit progresse par paliers successifs. Des qu'un palier est 
atteint, le suivant est accessible, et ainsi de suite jusqu'a atteindre la limite fixee. Dans 
le cas ou un palier n'est pas correctement valide parce que les acquittements des trames 
envoyees ne parviennent plus jusqu'a l'emetteur, le debit est automatiquement abaisse 
jusqu'a son palier le plus bas. En effet, si un seuil pose probleme, il ne sert a rien 
d'aller au suivant, car, avec un debit plus importan t, les erreurs risquent de se multi- 
plier, aggravant l'etat de saturation du reseau. En repartant d'un debit tres faible, 
l'emetteur allege la charge du reseau susceptible de le stabiliser et de reguler son etat 
avant que l'emetteur le sollicite. A nouveau, a partir du seuil le plus bas, la procedure 
d' augmentation de debit progressive est enclenchee. 

Toutes ces fonctionnalites assurent un service de transport fiable, mais posent globale- 
ment deux problemes. D'une part, elles engendrent un surplus de donnees important. 
D'autre part, ce n'est pas la fiabilite qui est l'element le plus important dans les commu- 
nications temps reel, mais le temps. 

Du fait des controles, chaque trame est enrichie d'un en-tete TCP. Dans les transmissions 
temps reel, les trames sont de petite taille, car le temps de mise en paquets par l'emetteur 
retarde la diffusion chez le recepteur. De plus, comme la diffusion doit se faire tres 
progressivement, les paquets sont decoupes par petits morceaux. Toutes les trames ont 
done un surplus consequent de donnees, appele overhead, constitue par 1' en-tete TCP, ce 
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qui est problematique pour la charge globale du reseau, dont les capacites sont limitees. 
Un interlocuteur, au lieu d'utiliser toute sa bande passante pour y coder la voix avec une 
bonne qualite, doit se contenter d'une qualite reduite afln de permettre l'ajout des 
donnees TCP. 

Concernant le temps, si une trame n'est pas correctement re^ue par un terminal, il n'est 
pas forcement utile de sollicker une reemission. Le temps d'etre re^ue a nouveau, la 
trame peut devenir obsolete et sans interet pour le recepteur. 

La figure 6.1 illustre ce qui ne devrait pas se produire. Alice envoie trois messages a 
Brigitte, contenant respectivement les mots « bonjour », « a », « tous » (il s'agit bien sur 
d'un cas d'ecole, le decoupage reel des trames se faisant a la duree et non au mot). Imagi- 
nons que seuls les mots « bonjour » et « tous » soient re^us par Brigitte. Avec le proto- 
cole TCP, une reemission du mot « a » va etre effectuee par le terminal d' Alice, une fois 
le temporisateur de reemission ecoule. Comme il s'agit d'une conversation telephonique, 
le terminal de Brigitte doit diffuser les messages rectus immediatement (en fait un 
systeme de cache permet de reduire plus ou moins cet effet, mais sans pallier le probleme 
pour autant puisqu'il n'offre qu'un delai supplementary limite). 

Si 1' application a delivre les deux mots re^us, il ne sert a rien de retransmettre le mot 
manquant par la suite, car celui-ci sera decorrele de la conversation. Sa diffusion aupres 
du recepteur produira une perturbation plutot qu'une amelioration. En outre, si un 
message est perdu, il est probable que la cause en soit la forte charge du reseau. En solli- 
citant une reemission de la trame, on accentue la charge et 1' engorgement du reseau. 

II est done preferable de perdre deflnitivement le paquet plutot que de le reemettre. 



Figure 6.1 

Reemission avec TCP 




Temporisateur 
de reemission 



Emis 



Transmis 



Reproduit 



Le protocole TCP est done bien inadapte au temps reel, puisque tous les controles qu'il 
met en place pour le transport des paquets penalisent ses delais de transmission. 

La contrainte de flabilite n'etant pas compatible avec la contrainte de delai imposee par 
la ToIP, TCP n'est done pas un bon candidat pour les transferts de type temps reel. 
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UDP et le transport de donnees multimedias temps reel 

Le protocole UDP ne comporte que des fonctionnalites de transport pur, sans aucun 
mecanisme de controle. L'adressage des donnees avec les ports de communication utili- 
ses est sa seule fonction fondamentale. C'est un atout par rapport aux elements contrai- 
gnants mentionnes pour le protocole TCP. UDP est ainsi notablement plus rapide que ne 
l'est TCP. 

Mais la simplicity de ce modele devient rapidement limitative. En particulier, UDP ne 
dispose d' aucun mecanisme lui permettant de reconstituer l'ordre des flux aupres du 
recepteur. Les datagrammes UDP sont totalement epures, et aucune estampille d'horoda- 
tage, ni de numerotation n'y est inseree. Or, dans un reseau IP, les paquets peuvent 
emprunter des chemins differents. Avec le seul protocole UDP, la sequence temporelle 
originale ne peut etre reconstitute au recepteur. 

En resume 

Des deux protocoles candidats au transport des donnees multimedias, Tun est « trop 
complet » et 1' autre trop limite. II est cependant possible de partir du protocole UDP et de 
lui ajouter des fonctionnalites d'ordonnancement. Le protocole RTP a ete propose a cette 
seule fin de reconstitution de l'ordre du flux d'origine. Pour sa part, RTCP a ete con^u 
pour offrir une vision de l'etat du reseau et permettre a une application d' adapter les flux 
en consequence. 



Figure 6.2 

Pile protocolaire RTP/RTCP 



Codec audio 

G.711,G.723, 
G.729,... 



Codec video 

H.261 , H263, ... 



I 
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UDP 
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La figure 6.2 illustre la pile protocolaire dans laquelle s'inserent generalement RTP et 
RTCP. Ces derniers etant independants de la couche reseau, ils peuvent fonctionner avec 
le protocole IP versions 4 ou 6 ou meme avec le protocole ATM. 

Notons que RTP et RTCP sont independants des couches basses et que leur utilisation 
conjointe avec UDP n'est qu'une application possible, meme si elle demeure la plus 
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courante. N'importe quel autre protocole de transport, IPX par exemple, pourrait 
parfaitement convenir. De meme, le choix du protocole de niveau reseau est laisse 
libre. 



Les protocoles RTP et RTCP 

Comme indique precedemment, le couple de protocoles RTP/RTCP a ete con^u dans le 
but d'enrichir les fonctions d'UDP et de fournir a ce dernier ce dont il a besoin pour gerer 
efflcacement les donnees multimedias temps reel. 

Aujourd'hui, ce couple s' utilise systematiquement dans les applications multimedias 
interactives, a la fois pour la telephonie, la video, les jeux video et la realite virtuelle. 

RTP (Real-time Transport Protocol) 

RTP a ete standardise par le groupe de travail AVT-WG (Audio Video Transport- Work 
Group) de 1'IETF. 

Decrit en Janvier 1996 dans la RFC 1889, rendue obsolete par la RFC 3550 en 
juillet 2003, il a ete fortement soutenu par de nombreux constructeurs et editeurs de 
logiciels, parmi lesquels Intel et Microsoft. 

Fonctionnalites 

RTP est utilise pour le transport de bout en bout de flux ayant des contraintes temporelles 
fortes, typiquement pour les flux multimedias avec interactivite, tel le service de telephonie 
sur IP. 

Initialement, RTP etait con^u pour un environnement multicast, dans lequel un emetteur 
diffuse son contenu vers plusieurs recepteurs en parallele. Le cas d'un flux unicast, dans 
lequel un emetteur n'emet que pour un unique recepteur, n'est qu'un cas particulier et 
plus simple d' application multicast. 

RTP assure un controle specifique des donnees temps reel. II permet de reconstituer les 
proprietes temps reel des flux medias en operant sur deux niveaux, la synchronisation des 
flux d'un cote et la reconstitution de l'ordre des paquets emis et la detection des pertes de 
paquets de 1' autre : 

• Synchronisation des flux. Si 1' audio et la video sont transmis separement, le destina- 
taire doit jouer la sequence audio de fa^on que cette derniere coincide avec la sequence 
video. Pour cela, RTP ajoute aux paquets emis une estampille de date, appelee horoda- 
tage, ou timestamp. Cette estampille indique le moment ou le paquet a ete emis, ce qui 
permet de reproduire les memes delais interpaquet et de jouer les paquets audio et 
video de maniere synchronisee. 

• Reconstitution de l'ordre des paquets emis et detection des pertes de paquets. Les 
paquets IP sont transmis independamment les uns des autres. En consequence, leur 
ordre d'arrivee chez le destinataire n'est pas forcement conforme a leur ordre d'emission. 
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Or cet ordre est indispensable pour reconstituer le message initial et le rendre intelli- 
gible a un auditeur. En recevant plusieurs paquets, le destinataire doit savoir lequel 
jouer avant les autres. Pour cela, un numero de sequence qui s'incremente progressive- 
ment est affecte a chaque paquet. Ce numero permet de determiner un ordre de 
preseance des paquets. Par effet de bord, il permet de determiner quels sont les paquets 
qui ont ete perdus. Si les paquets numerates i et i + 2 sont rectus, passe un delai 
d'attente maximal, le terminal recepteur en deduit que le paquet numerate i + 1 est 
manquant. 

Un mecanisme de compensation de la perte de paquets est generalement mis en place au 
niveau applicatif. Ce mecanisme n'est pas specifie par le protocole RTP, mais son usage 
est rendu possible par la detection des pertes. Par exemple, un mecanisme classique de 
compensation consiste a prolonger la duree d'ecoute des paquets precedents et suivants 
(les paquets i et i + 2 dans notre exemple), de fa^on a combler les pertes et reduire la 
perception humaine, tout en respectant la synchronisation des donnees. 

Format des paquets RTP 

Le format de l'en-tete d'un paquet RTP est illustre a la figure 6.3. 



Figure 6.3 

Format de l'en-tete 
RTP 



CC 



M 



PT 



Numero de 
sequence 



timestamp 



SSRC 



CSRC 



Les differents champs de l'en-tete RTP sont les suivants : 

• V pour version (sur 2 bits) : indique la version du protocole RTP utilisee. Actuellement, 
c'est la 2 qui est exploitee. 

• P pour padding (sur 1 bit) : bit indiquant si un bourrage est effectue dans les champs de 
donnees du flux multimedia. 

• X pour extension (sur 1 bit) : indique si l'en-tete possede une extension d'en-tete a sa 
suite. 

• CC pour CSRC Count (sur 4 bits) : nombre de sources ayant contribue a la generation 
du paquet. 



La qualite de service 



Chapitre 6 

• M pour marker (sur 1 bit) : indique si des descriptifs sont associes. 

• PT (sur 7 bits) : decrit le format de donnees. 

• Numero de sequence (sur 16 bits) : compteur increments d'une unite entre chaque 
paquet. 

• Timestamp (sur 32 bits) : estampille temporelle permettant la synchronisation des flux. 

• SSRC pour synchronization source (sur 32 bits) : identifie la source de la synchro- 
nisation. 

• CSRC pour contributing source (optionnel, sur n fois 32 bits) : identifie les contributeurs 
a la generation du paquet. 

Facultatif, le champ CSRC est utilise lorsque plusieurs sources ont contribue a la concep- 
tion d'un message. Le cas classique correspond a une conference au cours de laquelle 
plusieurs personnes conversent simultanement. Si une entite se charge de rassembler les 
flux avant de les relayer a chaque source (comme le fait la MCU), alors cette entite est 
source initiale du message, tandis que les contributeurs sont toutes les personnes qui ont 
emis leur flux vers elle. 

L'horloge utilisee pour le champ timestamp doit etre partagee par la source comme par 
l'emetteur. II faut done que Tun et 1' autre soient synchronises par une reference 
commune, et ce des le premier paquet echange. Pour cela, le protocole NTP (Network 
Time Protocol) est generalement utilise. II retourne l'heure courante, sous differents 
formats, aux differents intervenants. 

L' estampille temporelle et la numerotation des paquets comportent toutes deux des fonc- 
tionnalites d'ordonnancement, mais il n'y a pas de redondance entre ces deux parame- 
tres. L' estampille temporelle sert a synchroniser les flux, e'est-a-dire a preciser le 
moment ou le flux doit etre joue. De la meme fagon, si les flux video et audio sont 
envoyes separement, ce qui peut se reveler pratique si tous les intervenants d'une confe- 
rence ne peuvent ou ne veulent supporter les flux video mais se contentent des flux audio, 
1' estampille temporelle assure la concordance de la voix avec la video. 

En revanche, l'estampille temporelle ne permet pas de detecter les pertes. A l'inverse, la 
numerotation des paquets n' assure pas la synchronisation des flux mais permet de detec- 
ter les pertes. Les paquets perdus ne sont pas reemis, puisque les contraintes de temps ne 
le permettent generalement pas. Cependant, il est important de les detecter afin de 
permettre une synthese des paquets precedents et suivants et ainsi de rendre la perte 
de paquets moins sensible aux interlocuteurs. 

Exemple de mise en paquet et overhead 

Considerons une application audio qui utilise le codec G.711, e'est-a-dire qui transmet 
des donnees a un debit de 64 Kbit/s, et emet un paquet toutes les 10 ms. 

La figure 6.4 illustre les encapsulations successives qui vont etre appliquees aux donnees 
generees par le codec. 
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Figure 6.4 
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En 10 ms, pour respecter le debit de 64 Kbit/s, un paquet contiendra 80 octets de donnees 
utiles. Plusieurs en-tetes successifs vont etre appliques pour encapsuler ces donnees : 

• En-tete RTP, de 12 octets au minimum (repartis comme indique precedemment). 

• En-tete UDP de 8 octets (2 octets pour le port source, 2 octets pour le port destination, 
2 octets pour la longueur totale du datagramme et 2 octets pour le controle d'integrite 
du datagramme). 

• En-tete IP de 20 octets : 1 octet pour la version du protocole IP utilisee, 1 octet pour 
la longueur de 1' en-tete IP, 2 octets pour le type de service permettant la gestion de la 
qualite de service, 2 octets pour la longueur totale du paquet, incluant 1' en-tete IP, 
16 bits pour 1' identification d'un paquet IP, qui sont utilises, lorsque le paquet IP est 
fragmente, pour reconstituer les parties, 3 bits de drapeau, 13 bits indiquant la position 
d'un fragment pour recomposer les parties dans l'ordre, 1 octet pour le champ TTL, 
1 octet pour coder le protocole encapsule, 2 octets pour controler l'integrite du paquet, 
4 octets pour l'adresse IP source, 4 octets pour l'adresse IP destination. On ne compte 
pas les options de l'en-tete IP, qui ajouteraient 4 octets supplementaires. 

• En-tete Ethernet, de 26 octets : 8 octets de preambule pour la synchronisation des 
trames, 6 octets pour l'adresse MAC du terminal de destination, 6 octets pour l'adresse 
MAC du terminal source, 2 octets pour le type de protocole et 4 octets pour le CRC 
(controle de redondance cy clique), concatenes a la suite du paquet IP original. 
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On ne compte pas les eventuels octets de bourrage, et on utilise une version courante 
du protocole Ethernet, bien qu'il en existe d'autres. 

Au final, on arrive a 146 octets transmis dans un reseau LAN de type Ethernet toutes les 
10 ms. Cela equivaut a un debit effectif reel de 1 16,8 Kbit/s. Si Ton compare ce resultat 
avec les donnees reellement utiles transmises a un debit de 64 Kbit/s, on constate que le 
debit a presque ete double (il est 1,8 fois plus important). 

Dans les applications de telephonie, les paquets sont tres petits et sont done tres forte- 
ment surcharges par les en-tetes, pouvant etre 10 fois plus importantes avec certains 
codecs. Cette surcharge est appelee overhead. Elle comprend les donnees qui ne sont pas 
utiles, e'est-a-dire les donnees de transport non multimedias. Avec la video, les paquets 
sont plus importants, si bien que la surcharge devient globalement negligeable. 

Extensions et limitations 

Deux entites, le multiplexeur et le convertisseur, sont couramment utilisees avec RTP 
pour faciliter le transport des flux multimedias et les adapter : 

• Le multiplexeur permet d' adapter les flux aux utilisateurs. Le multiplexeur (en anglais 
mixer) est un equipement charge de multiplexer, resynchroniser et gerer les debits 
entre differents utilisateurs. Typiquement, lors d'une conference, si un intervenant 
dispose d'une forte bande passante tandis qu'un autre ne dispose que d'une faible 
bande passante, le multiplexeur re^oit les flux et fournit au premier un flux de haute 
qualite et au second un flux de moins bonne qualite. Le multiplexeur n'est pas un equi- 
pement transparent. II modifie les en-tetes RTP, en particulier le champ SSRC indiquant 
l'adresse de 1' equipement source ay ant produit le flux. 

• Le convertisseur permet de modifier les codages et de traverser les pare-feu. Le conver- 
tisseur (en anglais translator) adapte la syntaxe des flux entre les liens. Par exemple, si, 
entre deux reseaux, les debits sont differents, le convertisseur modifie le codec a la 
volee. Contrairement au multiplexeur, le convertisseur est un equipement transparent 
pour les utilisateurs, qui ne modifie pas les champs RTP. 

Une application classique du convertisseur concerne la securite. Considerons une confe- 
rence audio faisant intervenir plusieurs correspondants en multicast. Au sein d'une entre- 
prise, il est classique que les flux multicast soient prohibes en ce qu'ils sont potentielle- 
ment nuisibles aux reseaux et peuvent provoquer des attaques. Le convertisseur permet 
de contourner ce probleme. Pour cela, on met en place un traducteur devant et derriere le 
pare-feu, e'est-a-dire en entree et en sortie du reseau. 

Le convertisseur situe devant le pare-feu realise 1' operation suivante : l'adresse multicast 
avec laquelle l'emetteur envoie un paquet va etre transformee en l'adresse du convertis- 
seur situe derriere le pare-feu, et l'adresse multicast originale va etre sauvegardee et 
masquee a l'interieur du paquet. Ce flux deviendra ainsi licite puisqu'il ne sera plus 
multicast, mais seulement a destination du convertisseur situe derriere le pare-feu. II 
pourra done traverser le pare-feu. 
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Parallelement, le convertisseur situe derriere le pare-feu realise 1' operation inverse, en 
recevant les paquets. L'adresse unicast a laquelle le paquet est regu est remplacee par 
l'adresse multicast originale, qui se trouve a l'interieur du paquet. Le paquet est done 
envoye vers ses destinataires veritables. Le convertisseur permet de la sorte de contour- 
ner le pare-feu de l'entreprise en rempla^ant les flux unicast en flux multicast et recipro- 
quement. 

RTCP (Real-time Transport Control Protocol) 

Decrit dans la RFC 3550, RTCP est un protocole de controle et de supervision du reseau. 
II opere comme une sonde qui rend compte aux emetteurs des performances dont la 
communication en cours beneficie. Son objectif est d'offrir aux participants d'une 
session une vision sur l'etat du reseau et de s'y adapter de fa^on dynamique. II fournit 
pour cela un rapport sur la qualite de distribution, incluant le delai de bout en bout, la 
gigue et le taux de pertes. Ce rapport est envoye de fa^on periodique de fa^on que les 
intervenants disposent d'une mise a jour frequente de l'etat du reseau. 

Par exemple, si un utilisateur fait de la telephonie et que, par le biais du protocole RTCP, 
son correspondant lui envoie des rapports signalant un fort taux de perte de paquets, il 
peut considerer que le codec qu'il utilise est trop gourmand pour etre supporte dans les 
conditions actuelles du reseau. II peut des lors selectionner un codec de qualite un peu 
moins bonne mais necessitant moins de res sources. 

Dans sa specification, RTCP n'est aucunement indispensable pour le fonctionnement de 
RTP. La reciproque est vraie egalement. Neanmoins, leur association apporte une cohe- 
rence globale dans le traitement des communications multimedias. Tous deux doivent 
etre penses et integres au niveau applicatif. Les rapports fournis par RTCP peuvent opti- 
miser la qualite de la transmission. 

Les categories de paquets RTCP 

Les paquets RTPC sont classes en cinq categories : 

• SR (Sender Report). Ce type de paquet vehicule un rapport de l'emetteur, sous forme 
d'un ensemble de statistiques relatives a la qualite de service concernant l'emetteur. 
On trouve parmi ces informations le nombre de paquets perdus et la gigue mesuree par 
l'emetteur. La gigue est importante, car elle permet d'apprecier la regularity de 
l'arrivee des paquets transportant de la parole. On repere ces paquets SR par la valeur 
du champ PT (Payload Type), qui est mis a la valeur 201. 

• RR (Receiver Report). Ce type de paquet vehicule un rapport de recepteur, semblable 
aux paquets SR mais concernant le recepteur. La valeur du champ PT est 202. 

• SDES (Source Description). Ce type de paquet decrit une source, avec un ensemble de 
parametres specifiques parmi lesquels le nom permanent de la source, ou CNAME 
(Canonical Name), le nom du participant, name, son adresse e-mail, email, son 
numero de telephone (phone), sa localisation (loc), le nom de l'application qu'il 
utilise, avec si possible sa version (tool), et d'autres parametres speciaux (priv et 
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NOTE pour aj outer des informations complementaires). Ce type de paquet porte la 
valeur 203 dans le champ PT (Pay load Type). 

• BYE. Ce type de paquet est envoy e pour indiquer que l'emetteur quitte une session 
multimedia. Le champ PT (Pay load Type) prend la valeur 204. 

• APP (Application). Ce type de paquet est reserve pour transporter des parametres 
specifiques d'une application. Ce type de paquet est indique par la valeur 205 du 
champ PT (Pay load Type). 

La frequence des echanges de transmission des rapports doit etre dosee en fonction du 
type de media transports et du nombre de participants. Plus le nombre d'utilisateurs, et 
done de rapports echanges, est important, plus les rapports risquent de perturber les 
communications en reclamant une quantite de bande passante importante. En regie gene- 
rale, on considere qu'un overhead de 5 % par rapport aux donnees reelles est une borne 
maximale. 

RTP/RTCP et la qualite de service 

Les protocoles RTP et RTCP ne sont pas proposes pour garantir une qualite de service, 
lis ne supportent pas notamment les services suivants : 

• Reservation de ressources dans le reseau. Si, a un instant donne, le debit permet de 
faire de la video, le protocole RTP ne garantit en rien qu'a l'instant suivant ce sera 
toujours possible. 

• Fiabilisation des echanges. Une perte de paquets est equivalente au niveau du recep- 
teur a un silence. Le terminal du recepteur peut combler ces silences en allongeant la 
duree des messages vocaux precedents et suivants de fagon a masquer les manques et 
les rendre moins perceptibles a l'oreille. 

• Garantie des delais de transit dans le reseau. Les paquets peuvent etre retardes dans 
leur cheminement de bout en bout, et RTP ne garantit pas qu'ils seront regus au bon 
moment. La variation du delai de transit de bout en bout des paquets est pergue au 
niveau du recepteur par une voix saccadee. Pour reduire cet effet, l'utilisation de 
tampons (buffers) est necessaire arm de stabiliser la variation dans l'arrivee des 
paquets. 



Les controles au niveau reseau 

L'lETF propose deux grandes categories de services pour les controles reseau. lis se 
declinent en sous-services dotes de differentes qualites de service : les services inte- 
gres IntServ (Integrated Services) et les services differencies DiffServ (Differentiated 
Services). 

Les services integres sont geres independamment les uns des autres, tandis que les servi- 
ces differencies rassemblent plusieurs applications simultanement. La premiere solution 
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est sou vent choisie pour le reseau d'acces et la seconde pour l'interieur du reseau, 
lorsqu'il y a beaucoup de flots a gerer. 

Les services IntServ disposent des trois classes suivantes : 

• service garanti (Guaranteed Service) ; 

• service controle (Controlled Load) ; 

• best-effort. 

Les services DiffServ disposent des trois classes suivantes : 

• service garanti (Expedited Forwarding), ou service Premium ; 

• service controle (Assured Forwarding), ou service Olympic ; 

• best-effort. 

IntServ (Integrated Services) 

Le service IntServ integre deux niveaux de service avec garantie de performance. C'est 
un service oriente flot, dans lequel chaque flot peut faire sa demande speciflque de qualite 
de service. 

Pour obtenir une garantie precise, le groupe de travail IntServ a considere que seule une 
reservation de ressources etait capable de fournir a coup sur les moyens de garantir la 
demande. 

Comme explique precedemment, trois sous-types de services sont dermis dans IntServ : 
un service avec garantie totale, un service avec garantie partielle et le service best-effort. 
Le premier correspond aux services rigides, avec de fortes contraintes a respecter. Les 
deuxieme et troisieme sont des services dits elastiques, qui n'ont pas de contraintes 
fortes. 

Lorsqu'ils regoivent une demande via le protocole RSVP, les routeurs peuvent l'accepter 
ou la refuser. Cette demande s'effectue du recepteur vers l'emetteur apres une phase 
aller. Une fois la demande acceptee, les routeurs placent les paquets correspondants dans 
une file d'attente de la classe de service demandee. 

Le service IntServ doit pos seder les mecanismes suivants : 

• Procedure de signalisation pour avertir les noeuds traverses. Le protocole RSVP est 
suppose remplir cette tache. 

• Methode permettant d'indiquer la demande de qualite de service de l'utilisateur dans 
le paquet IP afin que les noeuds en tiennent compte. 

• Controle de traflc pour maintenir la qualite de service. 

• Mecanisme permettant de faire passer le niveau de qualite au reseau sous-jacent, s'il 
existe. 
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Le service garanti GS (Guaranteed Service) affecte une borne superieure au delai d'ache- 
minement. Pour cela, un protocole de reservation tel que RSVP est necessaire. La 
demande de reservation comporte deux parties : une specification de la qualite de service 
determinee par un FlowSpec et une specification des paquets qui doivent etre pris en 
compte par un flltre, le FilterSpec. En d'autres termes, certains paquets du flot peuvent 
avoir une qualite de service mais pas forcement les autres. Chaque flot possede sa qualite 
de service et son flltre, qui peut etre fixe (fixed filter), partage avec d'autres sources 
(shared-explicit) ou encore specifique (wildcard filter). 

Le service partiellement garanti CL (Controlled Load) doit garantir une qualite de 
service a peu pres egale a celle offerte par un reseau peu charge. Cette classe est essen- 
tiellement utilisee pour le transport des services elastiques. Les temps de transit dans le 
reseau des flots CL sont similaires a ceux de clients d'une classe best-effort dans un reseau 
tres peu charge. Pour arriver a cette fluidite du reseau, il faut integrer une technique de 
controle. 

Les deux services doivent pouvoir etre reclames par 1' application via une interface situee 
entre 1' application et le protocole de mise en place du service IntServ Deux possibilites 
sont proposees dans IntServ : 1' utilisation de la specification GQoS Winsock2, qui 
permet le transport d' applications point- a-point et multipoint, et RAPI (RSVP API), qui 
est une interface applicative sous UNIX. 

L'ordonnancement des paquets dans les routeurs est un deuxieme mecanisme necessaire. 
Un de ceux les plus classiquement proposes est le WFQ (Weighted Fair Queueing). Cet 
algorithme place dans chaque routeur demande une mise en file d'attente des paquets 
suivant leur priorite. Les files d'attente sont servies dans un ordre determine dependant 
de l'operateur. Generalement, le nombre de paquets servis a chaque passage dans le 
serveur depend du parametre de poids de la file d'attente. 

II existe de nombreuses solutions pour gerer la fa^on dont le service est affecte aux files 
d'attente, generalement fondees sur des niveaux de priorite. Citons notamment 1' algo- 
rithme Virtual Clock, qui utilise une horloge virtuelle pour determiner les temps d' emis- 
sion, et SCFQ (Self-Clocked Fair Queueing), qui travaille sur des intervalles de temps 
minimaux entre deux emissions de paquets d'une meme classe, intervalle dependant de 
la priorite. 

Le service IntServ pose le probleme du passage a l'echelle, ou scalabilite, qui designe la 
possibilite de continuer a bien se comporter lorsque le nombre de flots a gerer devient 
tres grand, comme c'est le cas sur Internet. Le controle IntServ s'effectuant sur la base de 
flots individuels, les routeurs du reseau IntServ doivent garder en memoire les caracteris- 
tiques de chaque flot. Une autre difficulte concerne le traitement des differents flots dans 
les nceuds IntServ : quel flot traiter avant tel autre lorsque des milliers de flots arrivent 
simultanement avec des classes et des parametres associes distincts ? 

En 1' absence de solution reconnue a tous ces problemes, la seconde grande technique de 
controle, DiffServ, essaie de trier les flots dans un petit nombre bien defini de classes, 
en multiplexant les flots de meme nature dans des flots plus importants, mais toujours en 
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nombre limite. IntServ peut cependant s'appliquer a de petits reseaux comme les reseaux 
d'acces. 

D'autres recherches vers des processeurs de gestion specialises dans la qualite de service 
ont debouche recemment sur des equipements capables de traiter plusieurs dizaines, 
voire centaines de milliers de flots. 

Le groupe de travail ISSLL (Integrated Services Over Specific Link Layers) de 1'IETF 
cherche a definir un modele IntServ agissant sur un niveau trame de type ATM, Ethernet, 
relais de trames, PPP, etc. L'objectif est de proposer des mecanismes permettant de faire 
passer le niveau de priorite de la classe vers des classes parfois non equivalentes et de 
choisir dans le reseau sous-jacent des algorithmes susceptibles de donner un resultat 
equivalent a celui qui serait obtenu dans le monde IP. 

DiffServ (Differentiated Services) 

Le principal objectif de DiffServ est de proposer un schema general permettant de 
deployer de la qualite de service dans un grand reseau IP et de realiser ce deploiement 
assez rapidement. 

DiffServ separe 1' architecture en deux composantes majeures : la technique de transfert 
et la configuration des parametres utilises lors du transfert. Cela concerne aussi bien le 
traitement re^u par les paquets lors de leur transfert dans un nceud que la gestion des files 
d'attente et la discipline de service, c'est-a-dire la fa^on dont les clients sont servis ; les 
disciplines de service les plus connues etant FIFO (First In First Out), LCFS (Last Come, 
First Served) et PS (Processor Sharing). La configuration de tous les nceuds du chemin 
s'effectue selon un critere appele PHB (Per-Hop Behavior). Ces PHB determinent les 
differents traitements correspondant aux flots qui ont ete differencies dans le reseau. 

DiffServ definit la semantique generale des PHB, et non les mecanismes specifiques 
permettant de les implemented Les PHB sont dermis une fois pour toutes, tandis que les 
mecanismes peuvent etre modifies et ameliores, voire etre differents suivant le type de 
reseau sous-jacent. 

Les PHB et les mecanismes associes doivent pouvoir etre facilement deployes dans les 
reseaux IP, ce qui demande que chaque noeud puisse gerer les flots grace a des mecanis- 
mes tels que 1' ordonnancement, la mise en forme ou la perte des paquets traversant un 
noeud. 

DiffServ agrege les flots en classes, appelees agregats, qui offrent des qualites de service 
specifiques. La qualite de service est assuree par des traitements effectues dans les 
routeurs specifies par un indicateur situe dans le paquet IP. Les points d'agregation des 
trafics entrants sont generalement places a 1' entree du reseau. Les routeurs sont configu- 
res grace au champ DSCP (Differentiated Service Control Point) du paquet IP, qui forme 
la premiere partie d'un champ plus general appele DS (Differentiated Service) et conte- 
nant aussi un champ CU (Currently Unused). Dans IPv4, ce champ DS est pris sur la 
zone ToS (Type of Service), qui est de ce fait redefinie par rapport a sa premiere utilisa- 
tion. Dans IPv6, ce champ se situe dans la zone TC (Traffic Class) de la classe de service. 
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La figure 6.5 illustre le champ DS des paquets IPv4 et IPv6. Le champ DSCP prend place 
dans le champ TOS (Type of Service) d'IPv4 et dans le champ Traffic Class d'IPv6. Le 
champ DSCP tient sur 6 des 8 bits et est complete par deux bits CU. Le DSCP determine 
la classe de service PHB (Per-Hop Behavior). 



Figure 6.5 
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Le champ de 6 bits du DSCP est interprete par le noeud afin d'attribuer au paquet le trai- 
tement correspondant a la classe PHB indiquee. Les deux bits CU sont ignores lors du 
traitement dans un noeud DiffServ normalise. Par 1' intermediate d'une table, les valeurs 
du DSCP determinent les PHB acceptables par le noeud. Une valeur par defaut doit 
toujours etre indiquee lorsque le champ DSCP ne correspond a aucun PHB. 

Les operateurs de telecommunications peuvent definir leurs propres valeurs de DSCP 
pour un PHB donne, a la place de la valeur recommandee par la standardisation de 1'IETF. 
Ces operateurs doivent toutefois fournir dans les passerelles de sortie la valeur standard du 
DSCP de fa^on que ce champ soit interprete convenablement par l'operateur suivant. En 
particulier, un DSCP non reconnu doit toujours etre interprete par une valeur par defaut. 

La definition de la structure du champ DS est incompatible avec celle du champ ToS de 
la RFC 791 definissant IPv4. Ce champ TOS avait ete congu pour indiquer les criteres a 
privilegier dans le routage. Parmi les criteres prevus se trouvent le delai, la fiabilite, le 
cout et la securite. 

Outre le service BE (best-effort), deux PHB assez semblables a ceux d'IntServ sont dermis 
dans DiffServ : 

• EF (Expedited Forwarding), ou service garanti, que Ton appelle aussi service Premium. 

• AF (Assured Forwarding), ou service assure, que Ton appelle aussi Assured Service ou 
Olympic. 

II existe quatre sous-classes de services en AF determinant des taux de perte acceptables 
pour les flots de paquets consideres. Elles sont classees en Platinium (platine), Gold (or), 
Silver (argent) et Bronze (bronze). Comme cette terminologie n'est pas normalisee, il est 
possible d'en rencontrer d'autres. 

A l'interieur de chacune de ces classes, trois sous-classes triees selon leur degre de prece- 
dence, c'est-a-dire leur niveau de priorite les uns par rapport aux autres, sont definies. La 
classe AFlx est la plus prioritaire, puis vient la classe AF2x, etc. II existe done au total 
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douze classes standardises, mais peu d'operateurs les mettent en oeuvre. En regie gene- 
rale, ces derniers se satisfont des trois classes de base du service AF, et done de cinq classes 
au total en ajoutant les services EF et BE. 

Les valeurs portees par le champ DSCP associe a ces differentes classes sont illustrees a 
la figure 6.6. Par exemple, la valeur 101110 du champ DSCP indique que le paquet est de 
type EF (Expedited Forwarding). La classe best-effort porte la valeur 000000. 



Figure 6.6 
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EF (Expedited Forwarding) : donnees expresses 

AF (Assured Forwarding) : donnees avec une qualite de service partielle 

BE (Best Effort) 



Le DSCP 1 1x000 est reserve a des classes de clients encore plus prioritaires que EF. II peut, 
par exemple, etre utilise pour des paquets de signalisation. 



EF (Expedited Forwarding) 

Le PHB EF (Expedited Forwarding) est defini comme un transfert de paquets pour une 
agregation de flots provenant de noeuds DiffServ dans laquelle le taux de service des 
paquets de l'agregat est superieur a un taux determine par l'operateur. Le traflc EF doit 
pouvoir recevoir un taux de service independamment des autres trafics circulant dans le 
reseau. En terme encore plus precis, le taux du traflc EF doit etre superieur ou egal au 
taux determine par l'operateur mesure sur n'importe quel intervalle de temps au moins 
egal a la taille d'une MTU (Mean Transmission Unit). Si le PHB EF est implements 
grace a un mecanisme de priorite sur les autres trafics, il faut que le taux de traflc de 
l'agregat EF ne depasse pas une certaine limite, qui deviendrait inacceptable pour les 
PHB des autres classes de traflc. 

Plusieurs types de mecanismes d'ordonnancement peuvent etre utilises pour repondre a 
ces contraintes. Une file prioritaire est le mecanisme le plus simple pour realiser le 
service (le PHB) EF tant qu'il n'y a pas d'autres files d'attente plus prioritaires. II est 
possible d'utiliser une file d'attente normale dans un groupe de files d'attente gerees par 
un mecanisme de tour de role avec poids (Weighted Round Robin) ou d'utiliser un 
partage de la bande passante de la file de sortie du nceud, permettant a la file EF d'attein- 
dre le taux de service garanti par l'operateur. Un autre mecanisme potentiel, appele 
partage CBQ (Class-based Queueing), donne a la file EF une priorite suffisante pour 
obtenir au moins le taux de service garanti par l'operateur. 
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Le trafic Expedited Forwarding correspond au traflc sensible au delai et a la gigue. II est 
dote d'une priorite forte dans les nceuds mais doit etre controle afin que la somme des 
traflcs provenant des differentes sources et passant sur une meme liaison ne depasse pas 
la capacite nominale determinee par l'operateur. 

Plusieurs solutions permettent de reserver la bande passante proposee aux flots de 
paquets EF. Un protocole de type RSVP, par exemple, peut effectuer les reservations de 
bande passante necessaires. Une autre solution consiste a utiliser un serveur specialise 
dans la distribution de la bande passante, ou Bandwidth Broker. Ce serveur de bande 
passante realise le controle d' admission en proposant une reservation centralisee. 

AF (Assured Forwarding) 

Les PHB AF (Assured Forwarding) assurent le transfert de paquets IP pour lesquels une 
certaine qualite de service peut etre garantie. Les traflcs AF sont subdivises en n classes 
AF distinctes. Dans chaque classe un paquet IP se voit assigner un taux de perte maximal 
et une priorite a la perte, correspondant a des classes de precedence. Un paquet IP qui 
appartient a la classe AFi et qui possede un taux de perte correspondant a la precedence j 
est marque par un DSCP AFij. 

Comme explique precedemment, douze classes sont definies pour DiffServ, correspon- 
dant a quatre classes AF avec des garanties sur la perte de paquets. Ces quatre classes 
correspondant aux taux de perte garantie sont appelees Platinium, Or, Argent et Bronze, 
chaque classe ayant trois niveaux de precedence differents. 

Les paquets d'une classe AF sont transferes independamment de ceux des autres classes 
AF. En d' autres termes, un noeud ne peut pas agreger de flots ayant des DSCP differents 
dans une classe commune. 

Un noeud DiffServ doit allouer un ensemble de ressources minimales a chaque PHB AF 
afin que ceux-ci puissent remplir le service pour lequel ils ont ete mis en place. Une 
classe AF doit posseder des ressources minimales en memoire et en bande passante pour 
qu'un taux de service minimal, determine par l'operateur, puisse etre realise sur une 
echelle de temps potentiellement assez longue. En d' autres termes, sur un intervalle de 
temps relativement long, pouvant se compter en seconde, une garantie de debit doit etre 
procuree aux services AF. 

Un noeud AF doit pouvoir etre configure pour permettre a une classe AF de recevoir plus 
de ressources de transfert que le minimum quand des ressources supplementaires sont 
disponibles dans le reseau. Cette allocation supplemental n'est pas forcement propor- 
tionnelle au niveau de la classe, mais l'operateur doit etre capable de reallouer les 
ressources liberees par la classe EF sur les PHB AF. Les precedences doivent toutefois 
etre respectees, une classe de meilleure precedence ne devant pas perdre plus de paquets 
qu'une classe avec une precedence inferieure, meme si la perte reste en dessous du 
niveau admissible. 

Un domaine implementant des services AF doit, par l'intermediaire des routeurs fron- 
tiere, etre capable de controler les entrees de traflcs AF pour que les qualites de service 
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determinees pour chaque classe AF soient satisfaites. Les routeurs frontiere doivent 
pour cela mettre en place des mecanismes de mise en forme du trafic (shaper), de 
destruction de paquets (dropper), d' augmentation ou de diminution des pertes de 
paquets par classe AF et de reassignation de traflcs AF dans d'autres classes AF. Les 
actions d'ordonnancement ne doivent pas causer de remise en ordre des paquets d'un 
meme microflot, un microflot etant un flot particulier a l'interieur d'un agregat d'une 
classe de PHB. 

L' implementation d'une strategic AF doit minimiser le taux de congestion a l'interieur de 
chaque classe, meme si des congestions de courte duree sont admissibles suite a des 
superpositions de flots continus de paquets (bursts). Cela demande un algorithme de 
gestion dynamique dans chaque noeud AF. Un exemple d'un tel algorithme est RED 
(Random Early Drop). La congestion a long terme doit aussi etre evitee grace a des 
pertes de paquets correspondant aux niveaux de precedence, et celle a court terme grace 
a des files d'attente permettant de mettre en attente certains paquets. Les algorithmes de 
mise en forme du trafic (shaper) doivent par ailleurs etre capables de detecter les paquets 
susceptibles d'engendrer des congestions a long terme. 

L' algorithme de base permettant d'effectuer le controle des traflcs AF est WRED, ou 
Weighted RED. II consiste a essayer de maintenir le reseau dans un etat fluide. Les pertes 
de paquets doivent etre proportionnelles a la longueur des files d'attente. En d'autres 
termes, les paquets en surplus puis les paquets normaux sont elimines des que le trafic 
n'est plus fluide. Le temps ecoule depuis la derniere perte sur un meme agregat est pris 
en compte dans l'algorithme. La procedure essaie de distribuer le controle a l'ensemble 
des noeuds et non plus au seul noeud congestionne. Les algorithmes de destruction de 
paquets doivent etre independants du court terme et des microflots, ainsi que des micro- 
flots a l'interieur des agregats. 

L' interconnexion de services AF peut etre assez difficile a realiser du fait de la relative 
imprecision des niveaux de service des differents operateurs s'interconnectant. 

Une solution pour permettre la traversee d'un agregat dans un reseau IP non 
conforme a DiffServ consiste a realiser un tunnel avec une qualite de service supe- 
rieure a celle du PHB. Lorsqu'un agregat de paquets AF utilise le tunnel, la qualite 
de service assuree par ce dernier doit permettre au PHB de base d'etre respecte a la 
sortie du tunnel. 

Un client qui demande un trafic Assured Forwarding doit negocier un agrement de 
service, appele SLA (Service Level Agreement), correspondant a un profil determine par 
un ensemble de parametres de qualite de service, nomme SLS (Service Level Specifica- 
tion). Le SLS indique un taux de perte et, pour les services EF, un temps de reponse 
moyen et une gigue du temps de reponse. Le trafic n' entrant pas dans le profil est detruit 
en priorite si un risque de congestion existe qui ne permettrait pas au trafic conforme 
d'atteindre sa qualite de service. 
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Architecture d'un noeud DiffServ 

L' architecture d'un noeud DiffServ est illustree a la figure 6.7. Elle comprend une entree 
contenant un classiflcateur (Classifier), dont le role est de determiner le bon chemin a l'inte- 
rieur du noeud. L'embranchement choisi depend de la classe detectee par le classiflcateur. 

Viennent ensuite des organes appeles Meter, ou metreurs. Un metreur determine si le 
paquet a les performances requises par sa classe et decide de la suite du traitement. Le 
metreur connait 1' ensemble des files d'attente du noeud ainsi que les parametres de 
qualite de service demandes par l'agregat auquel appartient le paquet. II peut decider de 
la destruction eventuelle d'un paquet, si sa classe le permet, ou de son envoi vers une file 
d'attente de sortie. Le noeud DiffServ peut aussi decider de changer ce paquet de classe 
ou de le multiplexer avec d'autres flots, comme nous le verrons. L'organe Dropper, ou 
suppresseur, peut decider de perdre ou non, c'est-a-dire de detruire ou non le paquet, 
tandis que le suppresseur absolu (Absolute Dropper) elimine automatiquement le paquet. 

En d'autres termes, le metreur (Meter) peut prendre une decision de destruction et 
envoyer le paquet dans un suppresseur absolu (Absolute Dropper), alors que le metreur 
(Meter) ne fait que determiner les parametres de performance et laisse au suppresseur 
(Dropper) le soin de detruire ou non le paquet suivant d'autres criteres que la mesure 
brute de la performance. 

Pour certains paquets, comme les paquets BE (best-effort), il n'est pas necessaire de se 
poser la question de la performance puisqu'il n'y a aucune garantie sur l'agregat. II suffit 
de savoir si le paquet doit etre perdu ou non. Cela correspond a la branche X sur la 
figure 6.7 Sur cette meme figure, la premiere branche (A) correspond aux clients EF ou 
Premium, les deux suivantes (B et C) a des clients AF, avec des clients Platinium ou Gold 
dans le chemin haut et Silver ou Bronze dans 1' autre chemin. 
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L' architecture d'un noeud DiffServ se termine par des files d'attente destinees a mettre en 
attente les paquets avant leur emission sur la ligne de sortie determinee par le routage. Un 
algorithme de precedence est utilise pour traiter l'ordre d'emission des paquets. L'ordon- 
nanceur (Scheduler) s'occupe de cette fonction. L' algorithme le plus simple revient a 
traiter les files suivant leur ordre de priorite et a ne pas laisser passer les clients d'une 
autre file tant qu'il y a encore des clients dans une file prioritaire. 

De nombreux autres algorithmes permettent de donner un poids specifique aux files 
d'attente, de telle fa^on qu'un client non prioritaire puisse etre servi avant un client prio- 
ritaire. Parmi ces algorithmes, nous avons deja evoque WFQ (Weighted Fair Queueing), 
dans lequel chaque file d'attente comporte un poids, par exemple 70 pour la file EF, 20 
pour la file AF Gold et 10 pour 1' autre file AF. L'ordonnanceur laisse passer pendant 
70 % du temps les clients EF. Si ces clients depassent l'utilisation de 70 %, l'ordonnan- 
ceur accepte de laisser passer des clients AF Gold pendant les 20 % du temps restant et 
pendant 10 % des clients AF Silver ou Bronze. 

L' ensemble des actions subies par un paquet dans un noeud DiffServ est realise par un 
organe general appele conditionneur (Conditioner). Un conditionneur de trafic peut 
contenir les elements suivants : metreur (Meter), marqueur (Marker), metteur en forme 
(Shaper) et suppresseur de paquets (Dropper). Un flot est selectionne par le classificateur. 
Un metreur est utilise pour mesurer le trafic en comparaison du profil. La mesure effec- 
tuee par le metreur pour un paquet peut etre utilisee pour determiner s'il faut envoy er le 
paquet vers un marqueur ou un suppresseur de paquet. 

Lorsque le paquet sort du conditionneur, il doit posseder la valeur appropriee du DSCP. 
Le metreur obtient les proprietes temporelles du flot de paquets selectionnes par le 
classificateur en fonction d'un profil determine par un TCA (Traffic Conditioning 
Agreement). Le metreur envoie ces informations aux autres organes du conditionneur, 
lesquels mettent en oeuvre des fonctions specifiques adaptees aux paquets afin que 
ceux-ci re^oivent les traitements appropries, qu'ils se trouvent dans le profil ou hors 
profil. 

Les marqueurs de paquets positionnent le champ DSCP a une valeur particuliere et ajou- 
tent le paquet au flux agrege correspondant. Le marqueur peut etre configure pour 
marquer tous les paquets a la bonne valeur du DSCP ou pour choisir un DSCP particulier 
pour un ensemble de PHB predetermine. 

Les metteurs en forme (Shaper) ont pour objectif de retarder des paquets d'un meme flot 
pour les mettre en conformite avec un profil determine. Un metteur en forme possede 
generalement une memoire de taille finie permettant de retarder les paquets en les 
mettant en attente. Ceux-ci peuvent etre detruits s'il n'y a pas de place disponible en 
memoire pour les mettre en conformite. 

Les suppresseurs detruisent les paquets d'un meme flot qui ne sont pas conformes au 
profil de trafic. Ce processus est parfois appele « policing » de trafic. Un suppresseur 
est parfois implements dans le metteur en forme lorsqu'un paquet doit etre rejete, s'il est 
impossible de le remettre dans le profil. 
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Les conditionneurs de trafic sont le plus souvent places dans les noeuds d' entree et de 
sortie des domaines DS. Puisque le marquage des paquets est effectue par les noeuds 
d' entree du domaine, un agregat provenant d'un autre operateur est suppose etre 
conforme au TCA approprie. 

L'ingenierie de trafic 

Les methodes de controle de la qualite de service que nous avons vues sont essentiel- 
lement statistiques. On joue soit sur le debit applicatif, en esperant que l'ensemble des 
debits pourra etre supporte par le reseau, soit sur des classes de service, afin de limiter le 
debit de la classe la plus haute, en esperant la encore que le debit total des flux les plus 
prioritaires restera suffisamment faible pour que le reseau soit fluide. 

Ces solutions sont surtout envisageables dans des environnements que le gestionnaire du 
reseau peut maitriser parce qu'il en connait les clients. Pour les reseaux d'operateurs, ces 
solutions ne sont guere acceptables etant donne la meconnaissance des flux qui peuvent 
potentiellement transiter a tout instant. C'est la raison pour laquelle les operateurs et les 
tres grandes entreprises se dirigent vers une autre solution, appelee ingenierie de trafic, 
pour assurer le controle de la qualite de service. 

Pour effectuer de 1' ingenierie de trafic, il faut savoir par ou passent les flux et connaitre 
leurs caracteristiques. La connaissance des flux de telephonie est particulierement 
simple, puisqu'elle depend principalement des codecs et de leurs parametres. Si Ton sait 
par ou passent les flux et si Ton connait leurs caracteristiques, l'ingenierie de trafic est 
une bonne solution. Le principal reseau qui effectue ce type de controle est MPLS et son 
extension GMPLS. 

Les caracteristiques les plus importantes de la norme MPLS (Multiprotocol Label-Switching) 
sont les suivantes : 

• Specification des mecanismes pour transporter des flots de paquets IP avec diverses 
granularites des flots entre un routeur, appele LSR (Label Switched Router), d' entree 
et un LSR de sortie. La granularite designe la grosseur du flot, lequel peut integrer plus 
ou moins de flots utilisateur. 

• Independance du niveau trame et du niveau paquet. En fait, seul le transport de paquets 
IP est pris en compte. 

• Mise en relation de l'adresse IP du destinataire avec une reference d' entree dans le reseau. 

• Reconnaissance par les routeurs de bord des protocoles de routage, de type OSPF 
(Open Shortest Path First), et de signalisation, tels LDP (Label Distribution Protocol) 
ou RSVP. 

• Utilisation de differents types de trames. 

Quelques proprietes supplementaires meritent d'etre soulignees : 

• L'ouverture du circuit virtuel est fondee sur la topologie, bien que d'autres possibilites 
soient egalement definies dans la norme. 



Theorie de la TolP 



Parte I 



• L'assignation des references est effectuee par l'aval, c'est-a-dire a la demande d'un 
noeud emettant un message en direction de l'emetteur. 

• La granularite des references est variable. 

• Le stock des references est gere selon la methode « dernier arrive premier servi ». 

II est possible de hierarchiser les demandes. 

Un temporisateur TTL (Time to Live) est utilise. Une reference est encapsulee dans la 
trame, incluant un TTL et une qualite de service. 

Le point fort du protocole MPLS reside dans la possibilite, illustree a la figure 6.8, de 
transporter les paquets IP sur plusieurs types de reseaux commutes. II est ainsi acceptable 
de passer d'un reseau ATM a un reseau Ethernet ou a un reseau relais de trames. En 
d'autres termes, il peut s'agir de n'importe quel type de trame, a partir du moment ou une 
reference peut y etre incluse. 



Figure 6.8 
Un reseau MPLS 
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Les transmissions de donnees s'effectuent sur des chemins nommes LSP (Label Switched 
Path). Un LSP est une suite de references partant de la source et allant jusqu'a la destination. 
Les LSP sont etablis avant la transmission des donnees {control-driven) ou a la detection 
d'un flot qui souhaite traverser le reseau {data-driven). 

Les references qui sont incluses dans les trames sont distributes en utilisant un proto- 
cole de signalisation, dont les plus importants sont LDP (Label Distribution Protocol) 
et RSVP (Resource reSerVation Protocol), eventuellement associes a un protocole de 
routage, comme BGP (Border Gateway Protocol) ou OSPF (Open Shortest Path 
First). Les trames acheminant les paquets IP transportent les references de noeud en 
noeud. 
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Les noeuds qui participent a MPLS sont appeles LER (Label Edge Router) et LSR 
(Label Switched Router). Un LSR est un routeur situe dans le coeur du reseau, qui 
participe a la mise en place du circuit virtuel par lequel les trames sont acheminees. Un 
LER est un noeud d'acces au reseau MPLS. Un LER peut avoir des ports multiples 
permettant d'acceder a plusieurs reseaux distincts, chacun pouvant avoir sa propre 
technique de commutation. Les LER jouent un role important dans la mise en place des 
references. 

Un equipement qui effectue a la fois une commutation sur une reference et un routage 
s'appelle un LSR. Les tables de commutation LSFT (Label Switching Forwarding Table) 
consistent en un ensemble de references d' entree auxquelles correspondent des ports de 
sortie. A une reference d' entree peuvent correspondre plusieurs files de sortie pour tenir 
compte des adresses multipoint. 

La table de commutation peut etre plus complexe. A une reference d' entree peut corres- 
pondre le port de sortie du noeud dans une premiere sous-entree mais aussi, dans une 
deuxieme sous-entree, un deuxieme port de sortie correspondant a la file de sortie du 
prochain noeud qui sera traverse, et ainsi de suite. De la sorte, a une reference peuvent 
correspondre tous les ports de sortie qui seront empruntes lors de l'acheminement du 
paquet. 

Les tables de commutation peuvent etre specifiques a chaque port d' entree d'un LSR et 
regrouper des informations supplementaires, comme une qualite de service ou une 
demande de ressources particuliere. 

Une FEC (Forward Equivalence Class) est une classe representant un ensemble de flots 
qui partagent les memes proprietes. Toutes les trames d'une FEC beneficient du meme 
traitement dans les noeuds du reseau MPLS. Les trames sont introduites dans une FEC au 
noeud d'entree et ne peuvent plus etre distinguees des autres flots a l'interieur de la 
classe. 

Une FEC peut etre bade de differentes fa^ons et avoir une adresse de destination bien 
determinee, un meme prefixe d' adresse, une meme classe de service, etc. Chaque LSR 
possede une table de commutation qui indique les references associees aux FEC. Toutes 
les trames d'une meme FEC sont transmises sur la meme interface de sortie. Cette table 
de commutation est appelee LIB (Label Information Base). 

Les references utilisees par les FEC peuvent etre regroupees de deux fa^ons : 

• Par plate-forme : les valeurs des references sont uniques pour 1' ensemble des LSR 
d'un domaine, et les references sont distributes sur un ensemble commun gere par un 
noeud particulier. 

• Par interface : les references sont gerees par interface, et une meme valeur de reference 
peut se retrouver sur deux interfaces distinctes. 

Une reference en entree permet de determiner la FEC par laquelle transite le flot. Cette 
solution ressemble beaucoup a la notion de conduit virtuel dans le monde ATM, dans 
lequel les circuits virtuels sont multiplexes. Ici, nous avons la meme chose, avec un 
multiplexage de tous les circuits virtuels a l'interieur d'une FEC, de telle sorte que, dans 
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ce conduit, Ton ne puisse plus distinguer les circuits virtuels. Le LSR examine la refe- 
rence et envoie la trame dans la direction indiquee. On voit le role capital joue par les 
LER, qui assignent aux Hots de paquets des references qui permettent de commuter les 
trames sur le bon LSR La reference n'a de signification que localement, puisqu'il y a 
modification de sa valeur sur la liaison suivante. 

Une fois le paquet classifle dans une FEC, une reference est assignee a la trame qui va le 
transporter. Cette reference determine le point de sortie par le chainage des references. 
Dans le cas des trames classiques, comme LAP-F du relais de trames ou d' ATM, la refe- 
rence est positionnee dans le DLCI (Data Link Connexion Identifier) ou dans le VPI/ 
VCI. Dans les autres cas, il faut ajouter un champ, le « shim label ». 

II est difficile de realiser une ingenierie de traflc dans Internet. L'une des raisons a cela 
est que le protocole BGP n'utilise que des informations de topologie du reseau. Pour 
realiser une ingenierie de traflc efflcace, 1'IETF a introduit dans 1' architecture MPLS un 
routage a base de contrainte, appele CR-LDP (Constraint-based Routing-LDP), et un 
protocole de routage interne a etat des liens etendu, appele RSVP-TE (RSVP-Trafflc 
Engineering). 

Comme nous l'avons vu, chaque trame encapsulant un paquet IP qui entre dans le reseau 
MPLS se voit ajouter par le LSR d' entree, ou Ingress LSR, une reference au niveau de 
l'en-tete. Cette reference permet d'acheminer la trame dans le reseau, les chemins etant 
prealablement ouverts par un protocole de signalisation, RSVP ou LDP. A la sortie du 
reseau, le label ajoute a l'en-tete de la trame est supprime par le LSR de sortie, ou Egress 
LSR. Au LSP (Label Switched Path), qui est le chemin construit entre le LSR d' entree et 
le LSR de sortie, sont associes des attributs permettant de controler les ressources attribuees 
a ces chemins. 

Ces attributs sont detailles au tableau 6-1. lis concernent essentiellement la bande 
passante necessaire au chemin, son niveau de priorite, son aspect dynamique par l'inter- 
mediaire du protocole utilise pour son ouverture et sa flexibilite en cas de panne. 

Tableau 6.1 - Attributs des chemins LSP dans un reseau MPLS 



Attribut 


Description 


Bande passante 


Besoins minimaux de bande passante a reserver sur le chemin du LSP 


Attribut de chemin 


Indique si le chemin du LSP doit etre specifie manuellement ou dynamiquement par 
I'algorithme CR-LDP. 


Priorite de demarrage 


Le LSP le plus prioritaire se voit allouer une ressource demandee par plusieurs LSP. 


Priorite de preemption 


Indique si une ressource d'un LSP peut lui etre retiree pour etre attribute a un autre 
LSP plus prioritaire. 


Affinite ou couleur 


Exprime des specifications administratives. 


Adaptability 


Indique si le chemin d'un LSP doit etre modifie pour devenir optimal. 


Flexibilite 


Indique si le LSP doit etre reroute en cas de panne sur le chemin du LSP. 
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Dans ce chapitre, nous avons introduit les differentes solutions permettant d'apporter de 
la qualite de service a un reseau IP. 

Les trois premieres solutions concernent les reseaux IP utilisant le routage. En tout 
premier, le protocole RTP/RTCP qui essaie d' adapter le flux applicatif aux possibilites du 
reseau : si le reseau devient charge alors 1' application doit ralentir en compressant de 
fa^on plus forte les donnees. Si le reseau devient peu charge, 1' application peut ameliorer 
sa qualite en transportant plus d' information. 

Cette solution qui est encore celle utilisee sur le reseau Internet est remplacee petit a petit 
par une autre methode : il faut que le reseau s'adapte a l'application et non le contraire. 
Dans ce cas, IntServ et DiffServ sont les deux propositions de 1'IETF. La premiere ne 
passant pas l'echelle, c'est DiffServ qui s'est impose. Les entreprises qui sont passees a 
la telephonie sur IP utilisent toutes un reseau DiffServ. Les operateurs preferent la solu- 
tion des reseaux commutes dans lesquels un chemin est trace. Dans ce cas, une ingenierie 
de trafic permet de bien maitriser les flots et de parvenir assez simplement a de la qualite 
de service. 

Les technologies futures, comme la fibre optique, en cours d' installation par les opera- 
teurs partout en France, nous laissent entrevoir des possibilites presque infinies en 
matiere de bande passante, qui promettent une meilleure stabilite aux applications tele- 
phoniques. 

De meme, le protocole IPv6 permettra d'etendre le champ d'adressage a 128 bits et 
contiendra dans son en-tete le champ de priorite DiffServ pour assurer les traitements 
privilegies aux donnees temps reel. 

Des protocoles tels que RTP et RTCP devraient neanmoins conserver leur role respec- 
tif, car ils n'assurent pas directement des fonctions de qualite de service, se contentant 
de controler les applications multimedias. Les plus grands industriels ont approuve et 
confirme 1' integration des protocoles RTP et RTCP au sein de leurs produits. Par 
ailleurs, ils ont egalement introduit ce protocole RTP/RTCP dans la conception 
d'autres protocoles. Ainsi le protocole H.323 integre-t-il RTP. De meme, le protocole 
SIP a delegue a RTP la tache de transporter les informations possedant des proprietes 
temps reel. 

Cependant, la solution qui s'impose aujourd'hui dans les entreprises est DiffServ. En 
effet, peu de complexity est ajoutee aux routeurs : ils doivent juste etre capables de lire le 
champ de priorite et de traiter les paquets en fonction de ce parametre. Toutes les entre- 
prises qui sont passees a la telephonie sur IP utilisent DiffServ. 

En revanche, la solution DiffServ est moins utilisee par les operateurs de telecommunica- 
tions et les FAI. En effet, la norme DiffServ ne fournit pas de garantie forte sur la qualite 
de service. Cette norme joue statistiquement sur le fait qu'il doit y avoir peu de clients 
prioritaires et done que ces clients traversent le reseau comme s'il etait vide. Pour les 
reseaux d'entreprise, cette hypothese est raisonnable, car on peut facilement surdimen- 
sionner les composants du reseau pour que les flux de ces clients prioritaires n'aient 



Theorie de la TolP 



Parte I 



aucun probleme. Dans un reseau d'operateur, beaucoup plus complexe, il n'est pas 
possible de jouer sur un effet statistique. De ce fait, il est preferable de miser sur des 
techniques de commutation de type MPLS, dans lesquelles il est facile de realiser de 
l'ingenierie de traflc puisque tous les paquets d'un meme client passent par le meme 
chemin a l'interieur du reseau. 
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Architectures et securite 



Dans ce chapitre, nous abordons les architectures de la ToIP dans differents types de reseaux. 

Nous commen^ons par examiner la telephonie sur Ethernet, puis sur ATM et enfin sur le 
relais de trames. Nous nous penchons ensuite sur la telephonie sur Wi-Fi, qui prend son 
essor grace aux Internet Box proposees par les operateurs. 

Nous introduisons en fin de chapitre la ToIP sur les nouvelles technologies WiMax pour 
reseaux metropolitains. 

La telephonie sur Ethernet 

La telephonie sur Ethernet concerne les entreprises qui souhaitent se doter d'un environ- 
nement de ToIP. Selon la taille de l'entreprise, cela peut concerner quelques postes de 
travail connectes a un meme reseau local, jusqu'a des infrastructures internationales 
permettant a des milliers de postes de travail de communiquer. 

Apres avoir examine les problematiques generates d' integration des services de ToIP et 
de donnees informatiques dans les reseaux d'entreprise, nous detaillerons les cas des 
reseaux d'entreprise a un seul site puis ceux des entreprises multisites. 

^integration voix-donnees 

Comme l'illustre la figure 7.1, une forte majorite d'entreprises utilisent deux reseaux 
differents pour transporter la parole telephonique et les donnees jusqu'au poste terminal 
de l'utilisateur. 

Le reseau telephonique est raccorde a un PABX (Private Automatic Branch eXchange), ou 
autocommutateur prive. Le reseau de donnees prend en charge les terminaux informatiques. 
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Parfois, un troisieme reseau s'occupe du transport d'images animees, comme un reseau 
de telesurveillance ou un reseau de distribution de television. 



Figure 7.1 
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Dans la nouvelle generation de reseaux d'entreprise, ces deux reseaux sont integres dans 
un meme reseau de type IP. Ce reseau unique est construit autour d'un reseau d'entreprise 
Ethernet. 

Cette generation de reseaux d'entreprise est illustree a la figure 7.2. Le reseau d'entre- 
prise comprend plusieurs sites, qui sont relies entre eux par un reseau d'operateur, qui 
peut etre de type VPN (Virtual Private Network). Dans chaque site, des telephones IP sont 
connectes a des commutateurs Ethernet. Les trois sites sont relies par un reseau IP 
d'operateur raccorde aux sites par le biais de routeurs. 



Figure 7.2 
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La partie telephonique de ce reseau est composee de terminaux telephoniques IP du type 
illustre a la figure 7.3. Ce telephone est en fait un routeur integrant un codec qui paquetise les 
octets telephoniques dans un paquet IP puis encapsule ce paquet dans une trame Ethernet. 
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Le telephone IP est capable de placer le bon niveau de priorite dans le paquet IP et de le 
translater dans la trame Ethernet. Le telephone IP dispose generalement d'une ou 
plusieurs sorties Ethernet pour connecter le telephone a un commutateur Ethernet, a un 
ordinateur personnel et a une autre machine IP. 



Figure 7.3 

Telephone IP 




Dans ce nouveau reseau integre, il faut que la parole transite dans des temps acceptables 
pour que 1' application telephonique puisse etre reconstitute en sortie. Pour cela, les tele- 
phones IP generent les trames Ethernet contenant les paquets IP qui transportent les 
octets de parole. 



Figure 7.4 
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Suivant le processus DiffServ, les paquets IP se voient attribuer la classe EF (Expedited 
Forwarding). Comme le reseau d'entreprise est compose essentiellement de commuta- 
teurs Ethernet, il faut que cette priorite des paquets IP de parole telephonique puisse etre 
prolongee dans les trames Ethernet. C'est le niveau de priorite situe dans la zone VLAN 
(Virtual LAN) qui s'en charge. 

Le format de la trame Ethernet VLAN, decrite dans les normes IEEE 802. 3ac et 
IEEE 802. lq, est illustre a la figure 7.4. 
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L'identificateur VLAN (VLAN Tag) de 4 octets contient un champ VPID (VLAN Proto- 
col IDentifler) et un champ TCI (Tag Control Information). Le champ VPID contient en 
general la valeur constante 0x8100 qui indique une trame de type 802. lq. Le VLAN Tag 
est insere entre l'adresse source et le champ Longueur/type du client MAC. 

Le champ TCI contient lui-meme les trois champs suivants : 

• Champ de priorite de 3 bits permettant jusqu'a huit niveaux de priorite. 

• Champ d'un bit, le bit CFI (Canonical Format Indicator), qui n'est pas utilise dans les 
reseaux IEEE 802.3 et doit etre mis a dans ce cas. 

• Champ VID (VLAN IDentifler) de 12 bits, qui indique l'adresse du VLAN. 

Le role du champ de priorite de 3 bits est primordial, car c'est lui qui permet d'affecter 
des priorites aux differentes applications. Cette fonctionnalite est decrite dans la norme 
IEEE 802. lp. Huit niveaux de priorites permettent d'autoriser des services temps reel 
comme la parole. 

La valeur 7 est reservee a la signalisation. La valeur 6 est celle que Ton utilise pour la 
telephonie (classe EF de DiffServ). Les classes 5 a 1 correspondent aux classes AF 
(Assured Forwarding) et BE (best-effort). 

II est possible que les trames Ethernet soient decapsulees pour passer dans un routeur. 
Dans ce cas, la zone DSCP du paquet IP est utilisee pour router selon la bonne prio- 
rite. 

Lorsqu'il existe deux reseaux distincts pour la voix et les donnees, l'environnement de 
telephonie est gere par un PABX tel que celui illustre a la figure 7.5. En cas de reseau 
unique, ce PABX centralise est remplace par un PABX distribue adapte au monde IP, 
appele un PBX-IP. 



Figure 7.5 

Fonctions d'un PABX 
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Dans la nouvelle generation de PBX-IP, la gestion des appels est realisee par un micro- 
ordinateur qui peut se trouver n'importe ou dans l'entreprise, sur n'importe lequel de ses 
sites. II peut egalement etre situe chez l'operateur (solution Centrex). La fonction de 
commutation est realisee par 1' ensemble des commutateurs de l'entreprise, de meme que 
les connexions des lignes telephoniques et des lignes telecoms. Seule la signalisation 
passe par une machine centralisee. 



La telephonie sur ATM 

La technique de transfert ATM a ete con^ue pour transporter de la parole telephonique de 
type G.71 1 a 64 Kbit/s. C'est la raison de la petite taille de la cellule ATM. 

Les 48 octets de donnees de la trame sont remplis en 48 fois 125 us, c'est-a-dire 6 ms, ce 
qui reste acceptable, meme lorsqu'il y a des echos et que le temps de transit doit rester 
inferieur a 28 ms. Si la parole telephonique est compressee par un codeur G.729 a 8 Kbit/s, 
il faut un temps de 48 ms de remplissage des 48 octets de donnees puisque le signal 
donne naissance a un octet a chaque milliseconde. 

L' emulation de circuit CES (Circuit Emulation Service) a ete la premiere solution adop- 
tee pour transporter de la telephonie en paquet. Cette emulation de circuit utilise la 
couche AAL1 (ATM Adaptation Layer de type 1) de l'environnement ATM, et plus preci- 
sement le service CBR (Constant Bit Rate). Les PABX interconnectes par cette solution 
utilisent des interfaces El normalisees (G.703 et G.704). Le service ATM est de type 
circuit virtuel permanent. La signalisation sur l'interface est portee dans TIT16 de l'inter- 
faceEl. 

Une autre solution, appelee VTOA (Voice and Telephony Over ATM), ne privilegie pas 
de protocole AAL specifique mais demande le support du service VBR-rt (Variable Bit 
Rate-real time). Le PABX est relie au noeud d'acces du reseau de l'operateur par un canal 
de type El structure. La signalisation utilise toujours TIT16 de l'interface ou un circuit 
virtuel permanent dedie. Des normes classiques, comme la recommandation CCITT n° 7 
ou QSIG (Q-Interface Signaling Protocol), une signalisation developpee par l'UIT-T, 
sont egalement utilisees. La parole elle-meme est transportee par des liaisons permanentes 
ou commutees. 



AAL2 



La couche AAL2, la troisieme du modele ATM, est celle qui s'occupe de la fragmenta- 
tion et du reassemblage des messages pour obtenir des blocs a la dimension des cellules 
ATM. Comme nous allons le voir, 1' AAL2 determine des fragments qui peuvent etre tout 
petits de fa^on a ne pas perdre de temps a attendre des octets telephoniques et a envoyer 
les fragments aussi vite que possible. 
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La parole etant aujourd'hui pratiquement toujours compressee, lorsque la compression 
est forte, comme lors de 1' utilisation du codeur G.723.1, qui diminue le debit du flot a 
6,3 Kbit/s, le temps de remplissage d'un paquet ATM devient tres long, meme pour une 
petite cellule. 

Un calcul simple montre que, pour remplir une cellule de 48 octets a la vitesse de 
6,3 Kbit/s, il faut plus de 60 ms. Ce temps est inacceptable si la communication genere 
des echos ou si d'autres temps d'attente incompressibles s'ajoutent. C'est notamment le 
cas de la parole numerique dans les reseaux de mobiles, dans lesquels, au temps de 
remplissage de la cellule, s'ajoute un temps d'acces important sur 1' interface air. Une 
solution possible, mais guere enthousiasmante, a ce probleme est de ne remplir que 
partiellement les cellules. En supposant, par exemple, une compression de 50 %, 
amenant le debit a 32 Kbit/s, si Ton veut garder les memes contraintes que pour des flux 
a 64 Kbit/s, il ne faut remplir les cellules qu'a moitie. Cette solution induit un flux a 
64 Kbit/s de cellules a moitie remplies. 

Le role de TAAL2 est de remplir une cellule d' octets provenant de plusieurs connexions 
de parole, mais avec des debits variables pour les differentes voies basse vitesse. La solu- 
tion du multiplexage des voies de parole a debit constant est simple, puisqu'il suffit de 
connaitre le numero de 1' octet pour recuperer le numero de la connexion. Lorsque les 
flux sont variables, il faut ajouter une information pour savoir a quelle voie de parole 
appartient le segment. 

Les microtrames AAL2 

Dans TAAL2, le multiplexage des voies de parole est effectue par des microtrames, 
appelees paquets CPS (Common Part Sublayer). La microtrame AAL2 est illustree a la 
figure 7.6. 



Figure 7.6 

La microtrame de I 'AAL2 
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L'en-tete de la microtrame tient sur 3 octets. La zone CID (Channel IDentifler) est un 
identiflcateur de la voie de parole. Sa longueur de 1 octet permet de multiplexer 
jusqu'a 248 voies de parole (les valeurs a 7 sont reservees). Le champ LI (Length 
Indicator) indique la longueur de la microtrame. Le champ UUI (User-to-User Indica- 
tion) permet de transmettre de l'information d'une extremite a 1' autre de la connexion. 
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Le champ HEC (Header Error Control) permet la detection et la correction des erreurs 
sur les deux octets precedents de l'en-tete. La longueur maximale d'une microtrame 
est de 64 octets, si bien que le transport d'une microtrame requiert parfois plus d'une 
seule cellule. 

Les microtrames etant encapsulees dans les cellules ATM, des bits de bourrage compe- 
tent la cellule pour arriver a une longueur de 47 octets, un octet etant reserve, comme 
dans l'AALl, pour transmettre des informations de controle. La cellule AAL2 est illustree 
a la figure 7.7. 



Figure 7.7 

La cellule AAL2 
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L' octet de controle permet de pointer sur le debut de la premiere microtrame encapsulee. 
En effet, il se peut que le debut d'une microtrame ait ete transports dans la cellule prece- 
dente. Pour trouver cette valeur, il faut connaitre la longueur de la derniere microtrame et 
compter les octets deja envoyes dans la fin de la cellule precedente. Le pointeur est reel- 
lement utile lorsqu'une cellule est perdue et qu'il faut retrouver le debut d'une micro- 
trame. Le pointeur requerant 6 bits, il reste 2 bits, qui permettent d'effectuer une nume- 
rotation modulo 2 et une verification de parite. 

Malgre la surcharge engendree par l'en-tete des micro-trames, 1' AAL2 est beaucoup plus 
efficace que 1' utilisation d'une connexion unique pour une voie de parole et, d'une fa^on 
generale, que la telephonie sur IP. C'est la raison pour laquelle les technologies de troi- 
sieme generation, comme l'UMTS ou HSDPA (High Speed Downlink Packet Access), 
ont adopte cette solution. 



La telephonie sur le relais de frames 

Le transport de la parole dans le relais de trames (Frame Relay) pose des problemes 
similaires a celui des reseaux ATM. Sur une liaison virtuelle, ou les paquets peuvent 
atteindre plus de 4 000 octets, il est indispensable de multiplexer sur une meme 
liaison plusieurs voies de parole. La proposition FRF. 1 1 du Frame Relay Forum decrit 
une solution de mini-trame semblable a celle de 1' AAL2 pour transporter les voies de 
parole. 

La possibilite d' avoir un commutateur occupe par la transmission d'une longue trame 
LAP-F cree toutefois une difficulte supplementaire. II faut done un mecanisme de prio- 
rite pour laisser passer les petits paquets portant de la parole telephonique. 
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Integration de la telephonie dans le relais de frame 

L' integration de la telephonie dans un reseau relais de trames est fortement utilisee 
depuis une dizaine d'annees. Elle reste une solution simple et peu onereuse, meme si de 
nouvelles solutions plus puissantes sont apparues depuis le debut des annees 2000. 

La figure 7.8 illustre l'integration de la voix et des donnees par l'intermediaire d'un 
VFRAD (Voice Frame Relay Access Device), un equipement capable de remplir des 
trames LAP-F dans un reseau en relais de trames. 




Figure 7.8 

Integration voix-donnees par un VFRAD 



Un VFRAD est un equipement qui permet d'encapsuler dans les trames LAP-F du relais 
de trames des octets de parole telephonique et de les multiplexer sur une meme liaison 
virtuelle, qui n'est autre qu'un circuit virtuel de niveau 2 tel que defini dans le relais de 
trames. 

Dans cette architecture, il faut autant de VFRAD que d'acces au reseau pour relier les 
differents sites entre eux, et les reseaux de chaque site ne sont pas integres. L'integration 
n'a lieu que sur le reseau relais de trames, ou une meme liaison virtuelle permet de trans- 
porter les trames de parole et de donnees. La parole telephonique peut etre restituee a 
l'arrivee, car le relais de trames comporte une option qui garantit le delai de transit dans 
le reseau. 
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Avec cette option, le transport de voix utilise une compression de la parole telephonique 
a un taux moyen de 8 Kbit/s. 

La figure 7.9 illustre l'integration des differentes applications dans cette solution. 
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Figure 7.9 

Integration voix-donnees dans le relais de trames 

Cette solution, normalisee en decembre 1998 par le Frame Relay Forum, met en ceuvre 
un mecanisme simple de point- a-point utilisant un circuit virtuel. La figure 7.10 illustre 
1' encapsulation de plusieurs voix de parole dans une trame suivie d'une trame de 
donnees. 
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Figure 7.10 

Integration voix-donnees au niveau trame 



La deuxieme solution que nous allons etudier est celle de l'integration dans un meme 
environnement IP de la parole telephonique provenant de combines analogiques et des 
donnees emises par les terminaux informatiques. Cette solution est decrite a la 
figure 7.11. 
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Les combines telephoniques analogiques sont relies a un PBX-IP, c'est-a-dire un auto- 
commutateur prive capable de generer en sortie des paquets IP transportant les octets de 
parole telephonique numerisee. Le PBX-IP gere egalement la supervision en transfor- 
mant la signalisation telephonique classique CCITT n° 7 en une signalisation capable de 
traverser le monde IP, comme H.323 ou SIP. 

Terminaux informatiques 



Serveur 




Figure 7.11 

Integration voix-donnees dans une architecture IP 



Dans cette solution, les paquets IP sont encapsules, au niveau des serveurs et des stations de 
travail IP, dans des trames Ethernet, lesquelles sont transmises sur un reseau Ethernet 
jusqu'au routeur de sortie de l'entreprise. Apres decapsulation de la trame Ethernet, les 
paquets IP sont integres dans une trame LAP-F du relais de trames pour etre achemines 
vers le routeur situe de 1' autre cote du reseau. Dans ce routeur, la trame LAP-F est de 
nouveau decapsulee afin de retrouver le paquet IP et d'inserer ce dernier dans une trame 
Ethernet. Cette trame est acheminee vers le terminal informatique ou vers le PBX-IP. 

Le reseau intersite peut etre un relais de trames, un reseau IP d'operateur ou un reseau IP 
prive d'entreprise. Le reseau de l'operateur peut s'appuyer sur des techniques diverses, 
comme ATM ou MPLS. Dans tous les cas, pour garantir la qualite de service necessaire a 
la parole telephonique, il faut que le reseau intersite soit capable de garantir un temps de 
transit au travers du reseau. Cette garantie est negociee avec l'operateur du reseau, opera- 
teur de telecommunications ou gestionnaire du reseau d'entreprise, de fa^on que les 
performances soient compatibles avec la qualite attendue par l'utilisateur. Pour cela, un 
SLA (Service Level Agreement) est negocie avec l'operateur du reseau, afin de preciser 
le temps maximal de transfert a l'interieur du reseau. 
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Dans cette solution, le reseau d'entreprise global doit posseder un reseau sur chaque site 
de l'entreprise et un reseau intersite, tous individuellement capables d' assurer une qualite 
de service, et done des temps de traversee bornes. On peut en deduire que le temps de 
transit d'un equipement terminal a un autre est borne. Ce temps doit rester inferieur a 150 
voire 300 ms pour une application de telephonic Pour cela, le reseau doit faire appel a 
des techniques de priorite permettant aux paquets prioritaires de voir le systeme comme 
etant quasiment vide. II faut done un surdimensionnement du reseau de site par rapport a 
la somme des debits des differentes voix telephoniques. Cela n'est generalement pas 
complique a obtenir avec des commutateurs Ethernet qui gerent les trois bits de priorite 
IEEE 802.3q et un reseau d'un debit egal a 100 Mbit/s. 

II faut en outre modifier les PBX en PBX-IP de fa^on que les octets de parole puissent etre 
encapsules dans des paquets IP. Une autre solution, allant jusqu'au bout de 1'integration dans 
IP, consiste a disposer de telephones IP capables de generer directement des paquets IP, de 
telle sorte qu'il n'y ait plus besoin de PBX-IP. Dans ce cas, un serveur de supervision prend 
en charge la signalisation afin de permettre de faire sonner le telephone distant. 

La figure 7.12 illustre cette solution d' integration du reseau d'entreprise dans un environ- 
nement completement IP. 

Terminaux informatiques 



Serveur 



Telephone-IP 




Figure 7.12 

Integration voix-donnees dans un reseau d'entreprise tout-IP 



Les avantages de cette solution proviennent du vrai multiplexage IP et de l'integration de 
bout en bout des applications voix et donnees. Ce tres haut degre d'integration rendra a 
moyen terme cette solution peu onereuse. A long terme, les couts devraient encore baisser 
du fait de l'arrivee en grand nombre d'operateurs IP proposant des SLA. 
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Parmi les inconvenients de cette technique, citons notamment les suivants : 

• mutation des equipements a mettre en ceuvre a relativement long terme ; 

• cout encore eleve des telephones IP ; 

• relative incompatibilite entre equipementiers des algorithmes de gestion de la qualite 
de service. 

De nombreuses solutions intermediaries, comme celle illustree a la figure 7.13, permet- 
tent a l'entreprise de passer doucement d'un environnement non integre a un environ- 
nement integre. Dans cette figure, le PBX est decoupe en plusieurs parties, des PBX-IP 
et des PBX non-IP. Les PBX-IP produisant les paquets IP sont raccordes aux routeurs, et 
les octets telephoniques transitent par la partie IP du VFRAD. Les PBX numeriques clas- 
siques integrent pour leur part leurs octets telephoniques directement dans une trame 
LAP-F du relais de trames. 

Les inconvenients de cette transition sont les suivant : 

• necessite d' avoir des equipements voix sur IP dans 1' ensemble des sites pour pouvoir 
recuperer les communications IP et les envoy er vers des PBX classiques ; 

• investissement dans des FRAD integrant la voix sur IP, c'est-a-dire des routeurs speci- 
fiques relativement couteux par rapport aux routeurs tout-IP. 




Figure 7.13 

Passage d'un environnement non integre a un environnement integre 
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La tendance a 1' integration est ineluctable. Vers les annees 2010, toutes les entreprises 
auront integre la telephonie et les donnees sur un meme reseau, ainsi que la video. La 
video genere en effet un flot de paquets synchrones, mais avec des contraintes temporel- 
les moins fortes. Elle s'integrera au reseau de l'entreprise des que les interfaces d'acces 
et les reseaux internes seront sufflsamment puissants. 



La telephonie sur reseaux sans f il 

Plus qu'une evolution technologique, la ToIP est aujourd'hui une application reseau 
incontournable, dont l'atout majeur est incontestablement le prix. 

Si les communications telephoniques sont generalement facturees a la duree et a la 
distance, les communications sur Internet sont le plus souvent forfaitaires, sans limitation 
de distance ni de temps. Toutes les applications dont les flux transitent sur le reseau Internet 
sont incluses dans le prix. Encore faut-il trouver les applications susceptibles de seduire 
les utilisateurs. La ToIP est precisement Tune des possibilites. 

Si la ToIP a pour principale vocation d'offrir une solution de rechange a moindre cout a 
la telephonie sur circuit classique, le sans-fll offre bien d'autres avantages. Les reseaux 
sans fil permettent aux utilisateurs de s'abstraire des contraintes de cablage sur les 
derniers metres de raccordement jusqu'a leur poste. La zone de couverture devient eten- 
due, ce qui procure une souplesse d' utilisation accrue. Le gain se traduit egalement par 
une facilite de deploiement et d'extensibilite du reseau, ce dernier devenant ambiant. 
C'est done presque naturellement que la ToIP a donne naissance a la telephonie sur 
reseaux sans fil, ou ToWLAN (Telephony over Wireless LAN). 

Cette nouvelle application ne va toutefois pas sans contraintes. II s'agit principalement 
d' assurer la portability en sans-fll des elements essentiels au deploiement de la voix. 

Contraintes de la ToIP sans fil 

La technologie de ToIP sans fil a pour objectif de permettre aux utilisateurs de telephoner 
directement en IP, done a un cout extremement bas et depuis de nombreux points sans 
avoir besoin d'une connexion physique. Elle represente un pas supplemental vers la 
convergence des flux audio, video et donnees sur un medium unique. 

La problematique de la ToIP sur WLAN est evidemment semblable a celle de la telepho- 
nie sur reseau terrestre, si ce n'est qu'il s'y ajoute la difficulte de realiser la traversee de 
1' interface air dans un laps de temps sufflsamment court pour satisfaire a la contrainte 
temps reel. II s'agit d'une vraie difficulte dans la mesure ou les equipements raccordes au 
point d'acces Wi-Fi sont a priori independants les uns des autres. De plus, les environne- 
ments Wi-Fi offrent un debit particulierement fluctuant, et il est quasiment impossible de 
connaitre le debit disponible a 1' instant suivant. 

Les terminaux de ToIP sur Wi-Fi assurent les fonctions de codec, de paquetisation et 
d' encapsulation dans la trame Ethernet pour transiter sur le reseau Wi-Fi. 
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Contraintes de la voix 

Dans la mesure ou la telephonie est une application d' utilisation courante, les usagers ont 
de fortes exigences a l'egard du service. En TolP, il est imperatif de respecter ces exigen- 
ces afin de rendre un service comparable a celui propose par la telephonie RTC ou PSTN 
(Public Switched Telephone Network). 

Dans une communication interactive, le temps constitue le plus fondamental des facteurs. 
Les deux parametres temporels necessaires pour assurer un confort d' utilisation raison- 
nable sont le delai de transit et la gigue. 

Le delai de transit sur le reseau (end-to-end delay) designe le laps de temps entre le 
moment ou l'emetteur prend la parole et celui ou le destinataire ecoute le message. II 
inclut en fait la somme des temps de conception du paquet au niveau de l'emetteur 
(numerisation, codage, compression, paquetisation), de traitement du paquet au niveau 
du recepteur (decodage, decompression, reassemblage, conversion du signal numerique 
en un signal analogique) et d'acheminement du paquet de bout en bout dans le reseau 
(delai de propagation, de transmission et de commutation dans les noeuds, incluant le 
delai de sejour dans les files d'attente des commutateurs). 

Pour ne pas perturber le rythme d'une conversation et assurer une interactivite entre les 
correspondants, ce delai doit etre aussi court que possible, comme nous l'avons vu au 
chapitre 2. Une tolerance de plusieurs centaines de millisecondes, voire de plusieurs 
secondes est admise pour le temps d'etablissement de la communication. Ce delai peut 
bien sur etre mis a profit pour configurer le reseau. Toutefois, le pourcentage de succes 
d'un appel initie doit etre superieur a 95 %, et la conversation ne doit jamais etre inter- 
rompue. La disponibilite du systeme constitue un element cle dans la fiabilite d'une 
application de voix sur IP. 

La gigue est un parametre egalement tres important de la parole telephonique. Prenons 
un exemple. Si les delais de transit de tous les paquets transportant une conversation tele- 
phonique sont egaux a 100 ms, la moyenne est egalement de 100 ms. Si maintenant le 
delai de transit d'un paquet sur deux est de 120 ms et d'un paquet sur deux de 80 ms, la 
moyenne est toujours de 100 ms mais la gigue a augmente, elle est passee de a 20 ms. 
Tant que la gigue reste acceptable, il est possible de resynchroniser les paquets. Mais 
lorsque la gigue augmente trop et depasse le temps maximal de latence, 1' application 
commence a se degrader. Par exemple, si le delai maximal acceptable dans une applica- 
tion de telephonie est de 150 ms et si la moyenne est de 100 ms mais la gigue de 
nombreux paquets est superieure a 50 ms, cela veut dire que de nombreux paquets ne 
pourront pas etre remis correctement puisqu'ils arriveront trop tard au recepteur. 

La telephonie sur IP peut offrir un ensemble de fonctionnalites supplementaires visant a 
simplifier son usage et a ameliorer la convivialite. C'est dans ce domaine que les services 
peuvent innover a moindre frais. Le nomadisme (possibilite de se connecter avec des 
informations de profils identiques dans des localisations distinctes) est ainsi rendu possi- 
ble par 1' attribution a un utilisateur d'un meme identifiant, quelle que soit sa localisation. 
II devient meme envisageable d' offrir la mobilite (possibilite de ne pas rompre une 
communication durant un deplacement). 
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Contraintes des transmissions sans fil 

Le cablage des terminaux est une operation souvent fastidieuse, surtout dans de nouvel- 
les installations. Avec le sans-fil, il n'est plus besoin de cabler les derniers metres qui 
relient l'utilisateur au reseau. Mais, dans ce cas, la ressource rare reste la bande passante. 
Les debits offerts sont limites et rarement garantis, ce qui constitue une contrainte 
majeure pour offrir la qualite de service indispensable a la voix. 

En outre, la transmission sans fil repose sur la qualite du lien radio. Or celle-ci depend de 
la qualite de l'interface radio, laquelle peut se degrader sous l'influence de plusieurs 
facteurs, tels que des interferences avec d'autres equipements utilisant la meme bande de 
frequences, des obstacles entre la source et la destination ou de l'eloignement important 
de l'emetteur et du recepteur. 

Un probleme a ajouter est l'independance des terminaux entre eux et done la quasi- 
impossibilite a priori d'introduire des priorites qui permettraient de favoriser la voix sur 
IP. Comme nous le verrons dans cette section, il est cependant possible d'introduire une 
certaine priorite, comme le propose la norme IEEE 802.1 le. 

Deja importantes dans les reseaux IP, les pertes de paquets sont particulierement couran- 
tes en sans-fil. La perte d'un paquet entraine la perte d'une bribe de parole. Pour une 
bonne qualite d'ecoute, le taux de perte de paquets doit etre inferieur a 20 %. Pour faire 
baisser le taux d'erreur sur l'interface radio, la technologie Wi-Fi reemet automati- 
quement les trames, augmentant d'autant le temps de traversee du reseau. 

Si le taux d'erreur depasse une certaine limite, la transmission d'un element binaire est 
effectuee sur deux signaux d'horloge a la place d'un seul, ce qui diminue le debit d'un 
facteur deux. Dans le cas d'un reseau IEEE 802.11b, le debit de base passe alors de 
1 1 Mbit/s a 5,5 puis a 2 puis a 1 Mbit/s. Cette baisse du debit pose un enorme probleme 
de qualite de service, puisque la bande passante n'est plus du tout celle attendue. De plus, 
le debit reel correspond approximativement a la moitie du debit brut. 

Une autre contrainte vient du fait que la confidentialite des communications entre 
usagers doit etre preservee des ecoutes clandestines. Cette precaution est d'autant plus 
indispensable lorsqu'il s'agit de transmissions sans fil, puisque l'interface air est par 
nature ouverte et accessible a toute personne situee dans la portee des ondes hertziennes. 
Bien qu' indispensable, la gestion de la securite engendre un debit supplementary, qui 
peut nuire aux donnees temps reel, ce qui necessite de trouver un compromis entre secu- 
rite et rapidite des flux. 

La qualite de service 

Au fur et a mesure que les normes des reseaux sans fil evoluent, les debits augmentent, de 
11 Mbit/s pour la version IEEE 802.11b a 54 Mbit/s pour 802.11a et 802.1 lg et 
190 Mbit/s pour la nouvelle version 802.1 In. Parallelement, les applications les plus 
courantes deviennent de plus en plus gourmandes en bande passante, si bien que les 
besoins croissent en meme temps que les debits. II devient des lors necessaire d' adapter 
une politique de gestion appropriee aux flux qui transitent dans le reseau. 
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Dans l'lnternet IPv4 que Ton utilise aujourd'hui, la qualite de service est de type best- 
effort, c'est-a-dire « au mieux », maniere detournee de dire que la qualite de service n'est 
pas geree, puisque tous les flux sont traites de la meme fa^on. Pour le traitement de la 
voix, c'est une technique insuffisante. II faut done differencier les flux selon leur impor- 
tance. 

En fait, il ne suffit pas de mettre en oeuvre un mecanisme sur une seule couche. II faut 
optimiser chacun des traitements pour les adapter aux specificites d'une application 
synchrone temps reel. On distingue deux manieres de gerer les flux : soit au niveau du 
routage de bout en bout, en reservant de la bande passante pour garantir un debit ou en 
differencial les flux, soit au niveau MAC, en adaptant 1'acces au support en fonction de 
la priorite des flux a transmettre. 

Nous avons vu au chapitre 6 differentes techniques de gestion de la qualite de service. 
Elles sont egalement applicables a la telephonie sur Wi-Fi, sauf pour l'interface radio, sur 
laquelle la gestion des priorites entre equipements distribues est complexe. 

Nous allons examiner en detail la technologie 802. lie, qui a ete mise au point pour intro- 
duce une forme de priorite en raccourcissant ou rallongeant les temporisateurs des equi- 
pements plus ou moins prioritaires. 

La norme IEEE 802.11 

Le role de la couche MAC (Medium Access Control) est de permettre a plusieurs stations 
d'acceder a un support partage. Dans le cas des reseaux sans fil, c'est l'interface air qui 
constitue le support des ondes hertziennes et permet de diffuser les donnees. Bien qu'elle 
soit specifique au reseau sans fil, la couche MAC definie par la norme 802.11 est tres 
proche de celle des reseaux Ethernet (802.3). 

802.11 definit differents temporisateurs intertrame, ou IFS (Inter-Frame Space), qui 
permettent d'instaurer des mecanismes de priorites differenciees selon le type de trames 
emises. Plus le temporisateur est court, moins la station doit attendre avant d'emettre et 
done plus sa trame est prioritaire. 

On distingue les quatre temporisateurs IFS suivants : 

• SIFS (Short IFS), qui accorde une priorite haute, essentiellement aux messages 
d'acquittement. 

• PIFS (PCF IFS), qui correspond a une priorite moyenne, permettant au point d'acces 
d' avoir un temps d'acces prioritaire par rapport aux stations, et est adapte aux services 
temps reel. 

• DIFS (DFC ou Distributed IFS), qui correspond a une priorite faible, de type best- 
effort et est generalement reserve a la transmission de donnees sans contrainte de 
temps. 

• EIFS (Extended IFS), le plus long des IFS, qui est utilise lorsqu'une erreur est 
detectee. 
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La norme 802.11 propose deux mecanismes elementaires de gestion de 1'acces au 
medium (la couche MAC) : la methode DCF (Distributed Coordination Function), avec 
contention, et la methode optionnelle PCF (Point Coordination Function), sans contention 
(pas de collision possible). 

DFC est la methode d'acces par defaut dans 802.11. Elle a ete con^ue pour prendre en 
charge des donnees asynchrones (sans priorite). Son fonctionnement repose sur le proto- 
cole CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance), ou acces 
multiple a detection de porteuse et evitement de collision. Ce dernier fonctionne selon 
trois procedures : l'ecoute de la porteuse, ralgorithme de back-off et l'utilisation d'acquit- 
tements positifs. 

L'ecoute du support precede toute transmission. Elle s'effectue sur deux couches distinc- 
tes du modele OSI. Au niveau physique, c'est le mecanisme PCS (Physical Carrier 
Sense) qui est utilise. II permet de detecter l'activite des autres stations en analysant les 
flux diffuses et transitant sur le support hertzien. Au niveau liaison, sur la sous-couche 
MAC, c'est le mecanisme VCS (Virtual Carrier Sense) qui determine l'activite du 
support. 

Pour cela, chaque station gere un temporisateur NAV (Network Allocation Vector) indi- 
quant la duree d' occupation du support, done le temps que les stations doivent attendre 
pour tenter d'emettre a leur tour. La duree de ce temporisateur est flxee en exploitant le 
contenu de trames speciales, appelees RTS (Ready To Send) et CTS (Clear To Send). 
Ces trames servent a effectuer une reservation explicite du support. 

Le message RTS est diffuse a l'initiative de la station qui souhaite emettre. II comporte 
l'indication de la station source, de la station destinataire et de la duree de la transmission 
envisagee (incluant la duree des messages d'acquittement du recepteur). Si le destinataire 
accepte la communication, celui-ci retourne un message CTS en reponse a la requete 
RTS. Comme toutes les stations qui veulent emettre sont a l'ecoute de l'activite du 
support, elles re^oivent egalement le RTS et/ou le CTS. Le champ de duree de ces trames 
leur permet de mettre a jour leur temporisateur NAV. 

Le mecanisme RTS/CTS permet de pallier le probleme de la station cachee. Ce probleme 
evoque le cas ou deux stations A et B sont trop lointaines l'une de 1' autre pour se detecter 
mutuellement et tentent de communiquer avec une meme station intermediate I. Dans ce 
cas, comme la station B n'entend pas lorsque la station A emet une trame a la station I, 
elle risque d'emettre elle-meme vers la station I une trame qui entrera en collision avec la 
trame de la station A. Avec le mecanisme RTS/CTS, la station B n'entend pas non plus 
la demande RTS faite par A, mais elle entend la reponse CTS diffusee par I. Ainsi, la 
demande prealable et surtout la reponse du destinataire permettent d'assurer qu'une seule 
station est en train d'emettre. 

Le mecanisme VCS est optionnel et peut etre applique systematiquement, a la demande 
ou jamais. En regie generate, son utilisation est preconisee lorsque les trames sont de 
grande taille. En cas de collision d'une trame, non seulement le support est parasite pendant 
toute la duree de la transmission, ce qui constitue un gaspillage de la bande passante, 
mais sa retransmission devient couteuse. Inversement, l'ajout de trames RTS/CTS peut 
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s'averer moins rentable que la perte de la trame a transmettre. II s'agit done de trouver un 
compromis. La perte (par collision, interference, etc.) d'une trame longue etant couteuse 
en bande passante, cette trame est fragmentee en unites appelees MSDU (MAC Service 
Data Unit) afln de restreindre les retransmissions eventuelles. Tous les fragments sont 
emis sequentiellement (sans nouvelle demande du support) et acquittes par le destina- 
taire, lequel se charge de reassembler les fragments. Le support n'est libere qu'apres la 
transmission de l'integralite de la trame. 

Le processus CSMA/CA debute par l'ecoute de la porteuse. Une station souhaitant emet- 
tre une trame verifle la disponibilite du support en l'ecoutant pendant un delai de valeur 
DIFS. Si cette condition est verifiee, la station peut emettre. Dans le cas contraire, elle 
poursuit l'ecoute jusqu'a ce que le support devienne libre. Afln de reduire la probability 
d' emission simultanee par plusieurs stations, elle enclenche ensuite une procedure 
fondee sur 1'algorithme de back-off. Dans cet algorithme, la station retarde sa transmis- 
sion pendant une duree, appelee back-off time, choisie aleatoirement et bornee entre les 
valeurs et CW. CW est la fenetre de contention (Contention Windows), comprise entre 
deux seuils predefinis CW^ et CW max . 

Si la disponibilite du support se conflrme tout au long de ce delai, la station est autorisee 
a emettre. A l'inverse, si une autre station vient a emettre durant ce delai, le temporisa- 
teur est suspendu tant que le canal reste occupe, et une nouvelle valeur de back-off time 
est choisie. Pour restreindre davantage les risques de collision, la valeur de la variable 
CW est incrementee (jusqu'a la valeur seuil maximale CW max ) a chaque tentative, selon 
la formule suivante : 

CW nouveau = (CW ancien+ l)xFP-l 

ou FP est un facteur de persistance fixe a la valeur 2 dans 1'algorithme de back-off et qui 
determine l'accroissement relatif entre deux retransmissions. 

L'acquittement positif permet de valider la reception des trames. Dans les systemes hert- 
ziens, la transmission de donnees couvre la capacite de reception d'un terminal, ce qui 
entraine qu'une station ne peut emettre et recevoir en meme temps. Par consequent, les 
collisions ne peuvent etre detectees lors de 1' envoi, mais seulement apres la diffusion 
complete de la trame. 

Pour reduire le nombre de collisions et accroitre les performances du reseau, le 
mecanisme de prevention de collisions est utilise. II consiste en un acquittement 
explicite par le recepteur, a defaut duquel l'emetteur est contraint d' emettre a 
nouveau sa trame, passe un delai d'attente determine. Ainsi, a la reception d'une 
trame, la station destination verifle son integrite, par le biais du champ CRC (Cyclic 
Redundancy Check), puis, si la trame est correcte, emet un acquittement (apres un 
delai SIFS). Si la station emettrice ne re^oit pas l'acquittement de sa trame, elle 
considere qu'une collision ou perte s'est produite et retransmet la trame. Apres un 
nombre predefini de tentatives sans acquittement, le support est considere comme 
instable, et remission est abandonnee. 
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Comme il se fonde sur CSMA/CA, qui est une methode probabiliste, le protocole DFC 
est efficace dans un reseau peu ou moyennement charge, mais se comporte de maniere 
moins efficace lorsque la charge du reseau est importante. Surtout, la qualite de service 
n'est pas geree avec DCF, puisque, par nature, CSMA/CA est un protocole avec 
contention equitable, qui ne permet pas de garantir un delai pour 1' acheminement des 
paquets. 

Optionnelle, la methode d'acces sans contention PCF (Point Coordination Function) 
proposee par le groupe 802.11 n'est utilisable que dans une configuration de reseau 
fondee sur une infrastructure, au sein d'une cellule appelee BSS (Basic Service Set), et 
est optimisee pour les transmissions a rythme regulier (isochrone), ce qui est particulie- 
rement utile pour les flux temps reels tels que la telephonic 

Dans ce mecanisme, les stations ne peuvent emettre ou recevoir des donnees que si elles 
y ont ete invitees par une station speciale, appelee Point Coordinator (PC). En pratique, 
le PC est implements au niveau d'un point d'acces. II est le seul a avoir le controle sur le 
droit d' emission. Son role est d'arbitrer l'acces au support en interrogeant tour a tour les 
terminaux pour savoir si ces derniers veulent emettre et de leur donner l'acces. Cette 
methode est appelee scrutation, ou polling. 

Concretement, le temps est divise en intervalles de temps, appeles supertrames, qui se 
composent d'une periode de contention CP (Contention Period) et d'une periode sans 
contention CFP (Contention Free Period). La periode avec contention utilise la methode 
d'acces DCF. La periode sans contention introduit un temporisateur PIFS, plus petit que 
le DIFS. Pendant cette periode CFP, le PC envoie aux stations destination des trames de 
donnees, appelees CF-Down, apres un delai PIFS. Les stations envoient quant a elles leur 
trame de donnees, appelee CF-Up, apres un delai SIFS. La periode sans contention se 
termine par une trame particuliere CF-End, precedee d'un delai PIFS. 

La methode PCF laisse done entrevoir la possibilite d'introduire de la qualite de service 
dans un reseau sans fll, mais ses contraintes deviennent vite limitatives. A chaque scruta- 
tion des stations par le coordinateur, une seule trame peut etre envoyee. En outre, la scru- 
tation des stations est un mecanisme peu scalable, compte tenu du temps offert systema- 
tiquement a toutes les stations, alors que nombre d'entre elles n'ont pas de trames a 
emettre. De surcroit, dans les trames emises, rien n'indique leur priorite par rapport a 
d'autres, si bien que le coordinateur ne peut favoriser un type de traflc en 1' absence de 
proflls types dermis. Aucune garantie de delai ni de gigue n'est possible. 

Par ailleurs, la methode PCF n'est pas efficace dans la situation de la station cachee. Une 
station situee en bordure d'un BSS est controlee par le PC de sa BSS. Si son PC l'auto- 
rise a emettre, rien n'indique que sa transmission ne va pas entrer en collision avec une 
station d'un BSS voisin. 

Le frein le plus lourd a 1' utilisation de PCF est sans doute le fait que cette methode ne 
fonctionne qu'en mode infrastructure, alors meme qu'elle est, dans la pratique, tres rarement 
implementee au niveau des points d'acces. 
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La norme IEEE 802.1 1e 

Aucune des methodes DCF ni PFC ne permettant de gerer de fa^on satisfaisante la 
qualite de service, la norme 802. lie s'est assigne l'objectif de specifier la gestion au 
niveau MAC de la qualite de service de fa^on a permettre aux paquets de telephonie de 
passer en priorite. 

Ce mecanisme repose sur le principe de differentiation de service au niveau du controle 
d'acces. Les stations gerent les priorites de leurs flux et y affectent des temporisateurs. 
Un flux temps reel a de la sorte un temporisateur d'emission plus court qu'un flux moins 
sensible au delai, ce qui le favorise pour emettre. Deux mecanismes de controle d'acces 
au support, EDCF et HCF, sont proposes sur ce principe. 

EDCF (Enhanced Distributed Coordination Function) est une amelioration de DCF pour 
la gestion de la qualite de service. II s'agit d'un mecanisme a contention qui reprend 
1'algorithme CSMA/CA. EDCF repose en fait sur une differentiation de services au 
niveau des flux. Ces derniers sont repartis en categories en fonction de leur priorite selon 
huit classes de traflc, de la valeur 7 (priorite la plus importante) a la valeur (priorite la 
plus basse). 

La valeur de ces priorites est donnee a la fois en fonction de celle affectee a un utilisateur, 
appelee UP (User Priority), et de celle affectee a 1' application utilisee, appelee TSPEC 
(Traffic SPECiflcation), qui peut etre dynamique. Par exemple, la priorite d'un flux associe 
a la voix est plus importante que celle associee a 1' envoi d'un e-mail. 

Un champ TID (Traffic IDentifier) de l'en-tete 802.11 porte la mention de la classe de 
traflc affectee a la trame. Ces priorites ont ete repertoriees en quatre categories de classes 
a 4 : pour les services best-effort, correspondant a 1' absence de priorite des flux asso- 
cies, 1 pour les flux video non interactifs, 2 pour les flux video interactifs (videoconfe- 
rence) et 3 pour les flux audio (telephonie notamment). 

Chacune de ces classes est geree a l'aide de files d'attente qui possedent un ensemble de 
parametres definissant la maniere dont l'acces au medium va se faire. On distingue 
essentiellement quatre parametres caracterisant une file d'attente. En premier lieu, la 
variable AIFS (Arbitration Interframe Space) definit un temporisateur avant emission. 
Elle joue un role analogue au DIFS dans la fonction DFS, mais sa valeur est ici arbitrai- 
rement fixee pour chaque classe, ce qui en favorise certaines aux depens d'autres. Sa 
valeur minimale est DIFS (voir figure 7.14). Les files d'attente sont d'autant plus priori- 
taires que la valeur de leur variable AIFS est faible. 



Les deux variables suivantes sont definies par le couple de variables CW min et CW max , 
qui caracterise une taille de fenetre de contention respectivement minimale et maximale. 
Le back-off time choisi dans 1'algorithme de back-off est compris entre ces deux seuils. 
En cas de collision, la fenetre de contention croit toujours selon 1'algorithme de back-off 
en utilisant la meme formule : 

CW nouveau = (CW ancien + 1) x FP[i] - 1 
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mais cette fois le facteur de persistance FP n'est plus fixe a la valeur 2 mais varie selon la 
priorite de la file d'attente numero i. Plus ces deux seuils sont faibles, plus le back-off 
time est court, et plus la station est privilegiee. 

Le quatrieme parametre est l'intervalle de transmission permis, appele TxOP (Transmis- 
sion Opportunity), qui definit pour chaque station un droit d' emettre ulterieurement. 
Cette variable definit le moment precis ou une station est autorisee a emettre, ainsi que la 
duree maximale accordee pour remission. Selon ce concept, les stations ne sont plus 
equivalentes, meme lors de remission de trames, certaines ayant un delai alloue plus 
long que d'autres. De surcroit, la contention sur le medium sans fil est effective au niveau 
du point d'acces qui distribue les valeurs des variables TxOP pour chaque station. 
Chaque file d'attente dispose ainsi d'un quadruplet de valeurs, instaure par defaut dans 
chaque station ou impose par le point d'acces lors du polling, selon les choix d' imple- 
mentation. 



Figure 7.14 
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La methode HCF (Hybrid Coordination Function), aussi appelee EPCF (Enhanced PCF), 
est une amelioration de PCF qui offre une gestion deterministe de l'acces au support sans 
collision. Le mecanisme est centralise par un coordinateur, appele HC (Hybrid Coordina- 
tor), en charge de 1' allocation du support pour chaque station. 

Comme pour PCF, le temps est divise en supertrames composees chacune d'une periode 
de contention et d'une periode sans contention. Durant la periode avec contention, c'est 
la methode EDCF qui est utilisee. Durant la periode sans contention, la station coordina- 
trice interroge les stations par polling. 

La transmission des donnees s'effectue alors selon deux modeles : soit le coordinateur 
emet en transmettant les trames regues aux stations concernees, soit il laisse les stations 
emettre, en leur distribuant des intervalles TxOP associes a la priorite qu'elles ont requise 
lors du polling. Autrement dit, le coordinateur controle l'acces au support et alloue le 
debut et la duree d' emission des stations en fonction de la priorite de leurs flux. En outre, 
le coordinateur peut acceder au support en un temps SIFS (quel que soit le type des 
trames qu'il emet) inferieur au temps PIFS utilise dans PCF, ce qui lui confere une prio- 
rite plus grande que n'importe quelle station de son BSS. 
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Le scenario fonctionnel de la methode HCF est illustre a la figure 7.15. 



Figure 7.15 
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En complement d'EDCF et de HCF, le mecanisme DLP et la methode d'acquittements 
cumulatifs ont ete ajoutes a la norme 802.1 le. 

DLP (Direct Link Protocol), ou protocole de lien direct, consiste a envoy er des trames 
d'une station a une autre sans passer par le point d'acces. Cela permet de communiquer 
directement avec son interlocuteur sans transiter par un intermediate. Cette solution 
n'impose pas de passer dans un mode particulier, le mode ad hoc, et assure automatique- 
ment la mise en relation des deux interlocuteur s, a conditions toutefois qu'ils se trouvent 
dans une meme cellule. Le temps de transmission s'en trouve reduit d'autant et l'efflca- 
cite de l'utilisation de la bande passante optimisee. 

La methode d'acquittements cumulatifs (burst acknowledgement) est une technique 
optionnelle de la norme 802.1 le qui ameliore l'efflcacite du canal en agregeant plusieurs 
acquittements en un seul. L'emetteur n'est pas contraint de se mettre en attente de recep- 
tion d'acquittement a chaque trame qu'il envoie, mais peut envoy er plusieurs trames de 
suite et attendre un acquittement global. 

Malgre les potentialites de cette norme, elle est loin d'etre parfaite et n'apporte qu'une 
priorite relative. Si deux stations risquent d'entrer en collision, elles vont etre separees 
par le mecanisme IEEE 802. lie, et la station la plus prioritaire passera avant la station 
non prioritaire. Si une premiere collision est evitee et que la station la moins prioritaire 
tire un long temporisateur, celui-ci peut arriver a echeance juste avant l'echeance d'un 
temporisateur beaucoup plus court d'une station hautement prioritaire qui aurait ete 
enclenche bien apres le temporisateur lent. Globalement, plus un point d'acces est charge 
et plus ce risque est grand. 

On peut en deduire que la norme IEEE 802.1 le n'apporte qu'une amelioration relative et 
que la meilleure solution est encore de s'assurer que les points d'acces ne sont pas char- 
ges du tout ou encore que le nombre de point d'acces est sufflsant pour que les terminaux 
soient toujours connectes a la vitesse la plus haute et que le debit total soit tres inferieur 
au debit maximal reel. 
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En resume 



Pour les operateurs comme pour les entreprises, le passage a la ToIP represente un cout 
relativement important, surtout s'il s'agit d'etendre la couverture aux reseaux sans fil. 
Mais ce ticket d' entree peut s'averer rentable et benefique si la technologie est a la 
hauteur de ce qu'elle remplace. 

Simplicite, interoperabilite, securite, mobilite et surtout qualite de service sont les 
composants de base pour convaincre les industriels comme les utilisateurs de franchir le 
pas. Tels sont les defis actuels que la ToIP dans les reseaux sans fil doit relever. 

Un standard unique s'imposerait plus facilement que 1' addition de tous les standards 
proposes, la difficulte etant de preserver les promesses mises bout a bout de ces tech- 
nologies. Une fois le standard approuve, 1' interoperabilite entre equipements a une 
large echelle imposerait aux constructeurs de respecter les memes normes d' imple- 
mentation. 

Alors meme que la ToIP n'est pas encore suffisamment deploy ee pour etre pleinement 
concurrentielle, les operateurs de telephonie classique se livrent a une guerre des prix. II 
est done probable que les avantages financiers des solutions de ToIP paraitront moins 
pertinents a l'avenir, d'autant que le ticket d' entree reste consequent. 

Une fois alignee sur les autres tarifs, la ToIP devra se demarquer par la richesse de services a 
valeur ajoutee qui restent encore a inventer. 

En constatant l'interet suscite par Wi-Fi aujourd'hui, on peut imaginer que le sans-fil 
devienne l'atout differenciateur pour l'emergence des technologies de ToEP. En cas de doute, 
la convergence des donnees vers un modele tout-IP, pour la voix, la video et les donnees a la 
fois, deviendra une evidence pour favoriser dans l'avenir l'essor de la ToEP sans fil. 



La telephonie sur WiMax 



L' initiative WiMax est nee du desir de developper des liaisons hertziennes concurrentes 
des techniques xDSL terrestres. Apres de longues annees d' hesitation, son vrai demar- 
rage a ete favorise par l'arrivee de la norme IEEE 802.16. 



WiMax fixe 



Le groupe de travail 802.16 a mis en place des sous-groupes, qui se sont attaques a des 
problemes distincts. 

Le groupe de travail de base a normalise un acces metropolitain dans la bande des 
10-66 GHz avec une vue directe des antennes entre elles et un protocole point- a-point. 
Finalisee en 2001, cette norme a ete completee en 2002 par la norme 802.16c, qui intro- 
duit des profils systeme WiMax, et par une partie de la norme 802. 16d de 2004, qui 
apporte des correctifs et des fonctionnalites supplementaires autorisant une stabilite de 
quelques annees pour la norme WiMax. 
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La reference qui sert de base aux equipementiers est appelee IEEE 802.16 2004. 

La norme 802. 16e (voir figure 7.16) a pour objectif d'etendre WiMax a des machines 
terminales mobiles, impliquant la possibilite de realiser des connexions xDSL vers des 
mobiles. Les frequences utilisees se situeront entre 2 et 3 GHz. 



802. 16e 
OFDMA 
scalable 



Acces sans fil fixe domestique 
et professionnel 



Premiere etape 
vers la mobilite IP 




OFDMA : Orthogonal Frequency 
Division Multiple Access 



Figure 7.16 

Reseau WiMax 802. 16e 



Les differences entre les normes 802.16 et 802.11 sont nombreuses. La couverture est 
beaucoup plus importante pour les premieres, puisqu'elle peut depasser 10 km, contre 
quelques dizaines a quelques centaines de metres pour les secondes. La technologie 
802.16 est moins sensible aux effets multitrajet et penetre mieux a l'interieur des bati- 
ments. Elle est de plus mieux con^ue pour assurer le passage a l'echelle, ou scalabilite, 
sur de grandes surfaces, c'est-a-dire sur des cellules de plusieurs kilometres carres au lieu 
de plusieurs centaines de metres carres. 
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Pour un meme canal de 20 MHz, WiMax permet de faire passer un peu plus de debit. La 
qualite de service est aussi plus facile a garantir. Les avantages de 802.11 par rapport a 
802.16 resident essentiellement dans son prix de revient faible, une forte reutilisation et 
un large succes commercial. 



WiMax-Mobile 



WiMax-Mobile, ou Wi-Mobile, ou encore Universal WiMax, correspond a la norme 
IEEE 802. 16e. Son objectif est de concurrencer les normes de reseau de mobiles 3G, 
comme l'UMTS ou le CDMA 2000. 

WiMax-Mobile s'adresse aux reseaux metropolitains sans fll mais adaptes aux connexions 
d'utilisateurs mobiles. Le standard WiMax-Mobile a ete finalise en decembre 2005, et 
les premiers equipements sont arrives sur le marche dans le courant de l'annee 2007. 
Le retard important par rapport aux normes deja en place dans le monde des mobiles, 
comme l'UMTS, ne pourra etre comble que par un cout tres inferieur de ces nouveaux 
equipements. 

La raison du prix de revient potentiellement tres bas de WiMax-Mobile est simple a 
expliquer. S'appuyant sur Ethernet et IP, ces reseaux seront totalement IP et geres par les 
protocoles du monde IP, a commencer par les protocoles de gestion de la mobilite, tels 
que IP Mobile, voire IP cellulaire ou autre. 

La securite des reseaux WiMax-Mobile sera globalement celle des reseaux sans fll. Le 
protocole IPsec sera le protocole de base pour la confldentialite des donnees transitant 
dans le reseau. 

Performances des reseaux WiMax-Mobile 

Un reseau WiMax-Mobile donnera la possibilite de se connecter en se depla^ant jusqu'a 
des vitesses de 130km/h avec gestion de la mobilite, c'est-a-dire avec handover pour 
passer d'une cellule a une autre. La taille des cellules pourrait etre de l'ordre de 1 km. 

Les antennes seront intelligentes. Elles se composeront d'une serie d'antennes dont les 
signaux seront combines de maniere variable arm de controler la reception et la transmis- 
sion. Une antenne principale sera accompagnee de plusieurs antennes secondaires secto- 
rielles projetant un grand nombre de faisceaux etroits vers l'abonne. Les differents 
signaux emis ou regus permettront de reconstituer de fa^on precise le signal original. 

Une nouveaute a remarquer par rapport aux autres reseaux issus du groupe 802 de 1'IEEE 
est la garantie de service incluse dans le protocole lui-meme. Cette derniere permettra a 
un utilisateur se trouvant dans une cellule et beneflciant d'un debit de 1 Mbit/s au 
moment de l'ouverture de sa connexion de maintenir ce debit pendant toute la duree de sa 
communication, independamment du nombre d'utilisateurs connectes. Dans les autres 
reseaux IEEE 802, au contraire, les ressources sont partagees entre les utilisateurs de 
maniere statistique. Lorsqu'un grand nombre d'utilisateurs se partagent un point d'acces, 
chacun d'eux a un debit faible. 
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Dans un reseau WiMax-Mobile, un client peut se voir refuser l'acces a la borne de 
connexion s'il n'y a plus de ressources sufflsantes dans le reseau, un peu a la maniere du 
signal d'occupation dans le reseau telephonique traditionnel. C'est la un changement 
d' orientation important dans la reflexion du groupe de travail IEEE 802.16. 

Classes de services WiMax pour la TolP 

Le reseau WiMax est dote de quatre classes de services pour la telephonie, et le reseau 
WiMax-Mobile de cinq. 

Les quatre classes de WiMax sont les suivantes : 

• UGS (Unsolicited Grant Service), devolu a la telephonie grace a une forte garantie de 
la qualite de service. 

• rtPS (Real-time Packet Service), qui correspond a des applications ayant de fortes 
contraintes temporelles, mais avec des debits qui peuvent etre variables. 

• nrtPS (Non-real-time Packet Service), qui correspond a des applications sans 
contraintes temporelles mais avec des contraintes de debit. 

• BE (best-effort), qui ne possede aucune garantie. 

Un mecanisme dit de Request-Grant a ete deflni par le groupe IEEE 802.16 pour gerer la 
transmission montante. Les stations doivent en tout premier lieu etre capables d' envoy er 
une demande de bande passante dans la trame en cours avant de pouvoir transmettre dans 
la trame suivante dans un slot reserve. 

L'acces au support physique de WiMax est de type TDMA (Time Division Multiple 
Access). II permet remission de trames successives, elles-memes decoupees en tranches, 
comme l'illustre la figure 7.17. 
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La voie descendante ne pose pas de probleme particulier puisque la station de base gere 
des transmissions de fa^on centralisee. Une voie de telephonie est emise regulierement 
dans des slots synchrones. 

Le probleme se complique avec la voie montante, puisque 1'algorithme d' allocation de la 
bande passante doit etre applique de fa^on distribute. La trame est divisee en trois parties 
temporelles. La premiere, appelee Initial Ranging Period, est composee d'un nombre fixe 
de mini-slots. Ces mini-slots sont alloues aux stations par la station de base afln qu'elles 
puissent indiquer leur portee, la bande passante demandee et si elles ont des paquets prets 
a etre emis. La seconde, appelee Contention Request Period, est reservee aux demandes 
des stations qui n'ont pas de contrainte temporelle. La troisieme et derniere est composee 
d'un ensemble de tranches de temps allouees aux differentes stations par la station de 
base a la suite des informations recueillies dans les deux parties precedentes. 

Dans la norme IEEE 802.16, les applications sensibles au delai et les applications qui 
doivent eviter les collisions reclament de la bande passante dans les mini-slots de la 
premiere partie et transmettent dans les tranches de temps qui leur sont allouees dans 
la trame suivante. C'est le cas des flots de telephonie sur IP. D'un autre cote, les applica- 
tions qui presentent une tolerance a l'egard du delai et les applications qui peuvent perdre 
du temps dans des collisions eventuelles reclament de la bande passante par l'interme- 
diaire des mini-slots de la periode de contention, la deuxieme trame. Une fois leur 
demande realisee avec succes, c'est-a-dire sans qu'une autre demande vienne entrer en 
collision avec la leur, une tranche de temps leur est affectee dans la trame suivante. 

Dans la version Universal WiMax une cinquieme classe de service est ajoutee pour la 
parole telephonique compressee. Dans WiMax, la classe de service mise au point pour 
la telephonie, appelee UGS (Unsolited Grand Service), ne propose qu'un flux constant, 
de telle sorte que si le flux telephonique est compresse et donne un debit variable, une 
perte de bande passante importante peut avoir lieu. La nouvelle classe s'appelle ertPS 
(enhanced real-time Packet Service). 



La securite 



Plus qu'une evolution technologique, la telephonie sur IP est aujourd'hui une application 
majeure du monde des reseaux. Son atout le plus important provient en partie de son inte- 
gration dans le reseau de donnees, qui rend son cout tres competitif. 

Si les communications telephoniques classiques sont generalement facturees a la duree et 
a la distance, les communications sur Internet sont forfaitaires. II n'existe aucune 
contrainte de distance et aucune limite de temps. La facture est uniquement fondee sur le 
debit offert. Ainsi, toutes les applications dont les flux transitent sur le reseau Internet 
sont comprises dans le prix. 

La technologie de ToIP est apparue il y a plus de dix ans. Elle a subi de multiples standar- 
disations internationales, qui, sans la mettre a l'abri des evolutions permanentes, inheren- 
tes aux technologies reseau, la rendent desormais suffisamment mature pour envisager un 
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deploiement a grande echelle. A condition toutefois de maitriser la securite et son inte- 
gration au monde du sans-fil. 

Les vulnerability dont les attaques peuvent tirer parti peuvent avoir cinq origines : 

• les protocoles ; 

• les logiciels ; 

• le sy steme d' exploitation ; 

• 1' infrastructure physique ; 

• 1 ' erreur humaine. 

Chacune d'elles est une source potentielle de faille, qu'il convient d'etudier avec precaution 
dans la mise en place d'une solution de TolP. 

Une attaque peut avoir trois objectifs : 

• Acquisition de service. L'objectif d'une telle attaque est de s'approprier des droits et 
fonctionnalites qui n'ont pas veritablement ete attribues a l'attaquant. 

• Interception de service. Cette attaque compromet la confldentialite du service et vise a 
en analyser ou modifier le contenu. 

• Interruption de service. L'objectif est purement de nuire au bon deroulement du 
service en cherchant a le mettre hors d' usage. 

La securite de 1' application de telephonie sur IP n'est pas vraiment differente de celle des 
autres applications du monde IP. Nous allons dans un premier temps examiner les attaques 
possibles. 



Les attaques 



Les attaques de securite reseau sont divisees en attaques passives et actives. Ces deux 
classes sont elles-memes divisees en sous-classes. Les consequences de ces attaques sont 
le cout legal et de recouvrement et la perte d' informations proprietaries, d'image ou de 
services reseau. 

Une attaque est dite passive lorsqu'un individu non autorise obtient un acces a une 
ressource sans modifier son contenu. Les attaques passives peuvent etre des ecoutes ou 
des analyses de traflc, parfois appelees analyses de flot de traflc. 

Ces deux attaques passives presentent les caracteristiques suivantes : 

• Ecoute clandestine, ou eavesdropping. L'attaquant ecoute les transmissions pour recu- 
perer le contenu des messages. Par exemple, une personne ecoute les transmissions sur 
un reseau LAN entre deux stations ou bien ecoute les transmissions entre un telephone 
sans fll et une station de base. Des outils tels que VoIPong, Vomit, Cain and Abel, 
Oreka ou Angst permettent de reconstituer des communications telephoniques. 

• Analyse de traflc, ou sniffing. L'attaquant obtient des informations en surveillant les 
transmissions pour detecter des formes ou des modeles classiques dans la communication. 
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Une quantite considerable d' information est contenue dans la syntaxe des flots de 
messages transitant entre des parties communicantes. Des programmes tels que 
Siprogue, Sipsak, SiVuS, Dsniff ou Wireshark permettent d'effectuer ce genre d' inter- 
ception. 

Une attaque est dite active lorsqu'un parti non autorise apporte des modifications aux 
messages et flux de donnees ou de fichiers. II est possible de detecter ce type d' attaque. 

Les attaques actives peuvent prendre la forme d'un des quatre types suivants, seul ou en 
combinaison : 

• Mascarade. L'attaquant usurpe l'identite d'un utilisateur autorise et obtient ainsi 
certains privileges d'acces. Des outils tels que Registration Hijacker, Registration 
Eraser, Registration Adder ou RedirectPoison permettent d'effectuer ces manipula- 
tions. 

• Rejeu. L'attaquant surveille les transmissions (attaque passive) et retransmet les 
messages a un utilisateur legitime. Ce type d' attaque n'est pas possible dans le cas de 
la telephonie puisque le rejeu n'est pas envisageable dans le cadre d'une application 
interactive. Le rejeu pourrait eventuellement s'appliquer au cours de l'authentiflcation. 
Un programme tel que AuthTool permet de realiser ce genre d' exploit. 

• Modification de message. L'attaquant altere un message legitime en supprimant, ajou- 
tant, modiflant ou reordonnant du contenu. La encore la telephonie sur IP n'est pas 
concernee directement, mais des programmes dedies existent, tels RTP InsertSound ou 
RTP MixSound. 

• Deni de service, ou DoS (Deny of Service). L'attaquant previent ou interdit l'usage 
normal ou la gestion des moyens de communication. Par exemple, en envoyant des 
messages en masse, les ressources d'un equipement peuvent saturer. Des logiciels tels 
que UDP flooder, RTP flooder, INVITE flooder ou IAX flooder sont con^us a des fins 
d' audit, avec les risques d' utilisation que cela suppose. 

Ce dernier type d' attaque est une source de menace redoutable pour les solutions de 
securite logicielle, puisque la securite est facilement mise en cause en cas de modifica- 
tion malveillante des programmes charges d'appliquer les protocoles et les regies de 
controle. 

L' attaque par deni de service est une des plus simples a mettre en ceuvre et est generale- 
ment tres difficile a parer dans les reseaux sans fil. Le deni de service est obtenu lorsque 
1' element que Ton attaque est submerge de messages et ne peut repondre a la demande. 
Dans le cas classique, les pirates occupent un grand nombre de postes de travail et leur 
font emettre des flots ininterrompus de messages qui convergent vers 1' element attaque. 
La parade est difficile puisque l'attaque peut etre soudaine et qu'il n'est pas evident de 
prevoir cette convergence. 

Dans un reseau sans fil, un deni de service consiste a emettre un grand nombre de reque- 
tes d'attachement vers le point d'acces jusqu'a le faire tomber. II est pour le moment 
impossible d'empecher un utilisateur d'emettre ce flot de requete, meme s'il n'est pas 
autorise a se connecter. A chaque requete, le point d'acces doit executer une suite 
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d' instructions avant d'effectuer le refus. La seule parade connue consiste a determiner le 
point d'ou provient l'attaque et a lancer une intervention humaine de neutralisation. 

De nombreuses attaques de deni de service peuvent s'effectuer par l'intermediaire du 
protocole ICMP (Internet Control Message Protocol). Ce protocole est utilise par les 
routeurs pour transmettre des messages de supervision permettant, par exemple, d'indi- 
quer a un utilisateur la raison d'un probleme. Une attaque par deni de service contre un 
serveur consiste a generer des messages ICMP en grande quantite et a les envoyer au 
serveur a partir d'un nombre de sites important. 

Pour inonder un serveur, le moyen le plus simple est de lui envoyer des messages de type 
ping lui demandant de renvoyer une reponse. On peut egalement inonder un serveur par 
des messages de controle ICMP d'autres types. 

Dans l'attaque par cheval de Troie, le pirate introduit dans la station terminale un 
programme qui permet de memoriser le login et le mot de passe. Ces informations sont 
envoy ees vers l'exterieur par un message destine a une boite a lettres anonyme. Diverses 
techniques peuvent etre utilisees pour cela, allant d'un programme qui remplace le 
gestionnaire de login, jusqu'a un programme pirate qui espionne ce qui se passe dans 
le terminal. 

Ce type d'attaque est assez classique dans les reseaux sans fll puisqu'un client peut 
s'immiscer, via le point d'acces, dans un PC et y installer un logiciel espion lui permettant 
de prendre la place de 1' utilisateur. 

Beaucoup de mots de passe etant choisis dans le dictionnaire, il est tres simple pour un 
automate de les essayer tous. De nombreuses experiences ont demontre la simplicite de 
cette attaque et ont mesure que la decouverte de la moitie des mots de passe des 
employes d'une grande entreprise pouvait s'effectuer en moins de deux heures. 

Une solution simple pour remedier a cette attaque consiste a complexifier les mots de passe 
en leur ajoutant des lettres majuscules, des chiffres et des signes comme !,?,&, etc. 

L'attaque par dictionnaire est l'une des plus frequentes dans les reseaux sans fll qui ne 
sont proteges que par des mots de passe utilisateur. 

II est possible de compromettre une communication en diffusant de faux messages RTP, 
congus par un attaquant comme s'ils faisaient partie d'une communication mais qui 
perturbent en realite la reception du message audio pour le rendre incomprehensible. 

En considerant le protocole de signalisation SIP, on peut imaginer des attaques a la fois 
par des requetes et par des reponses, notamment les suivants : 

• Un message bye correctement forge par un attaquant peut mettre fin a la communication 
d'autres personnes. 

• Un message register contenant un enregistrement d'un utilisateur fictif est envoy e en 
masse vers un serveur d' enregistrement afin de saturer les capacites de stockage de ce 
dernier ou de le surcharger. 
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• Un message register contenant un enregistrement d'un utilisateur reel vers une 
localisation inexacte risque de detourner la communication vers la localisation mentionnee. 

Des attaques similaires sont envisageables avec les autres protocoles de signalisation. 

Les securites a mettre en place 

La securite dans les reseaux telephoniques classiques est particulierement forte. La 
disponibilite du reseau y atteint les 5«neuf», c'est-a-dire que le systeme marche 
99,999 % du temps. Avec la telephonie sur IP, il faut introduire des elements de securite 
supplementaires puisque le support est partage et qu'une ecoute peut se produire. 

Classiquement, la securite s'appuie sur cinq services de base : 1' identification, l'authenti- 
flcation, la confldentialite, l'integrite des donnees et la non-repudiation. 

L' utilisateur d'un systeme ou de ressources quelconques possede une identite, sorte de 
cle primaire d'une base de donnees, qui determine ses lettres de credits (credentials) et 
autorisations d'usage. Cette identite peut etre veriflee de multiples manieres, par exemple 
par la saisie d'un compte utilisateur (login) ou au moyen de techniques biometriques, 
telles que les empreintes digitales ou vocales, les schemas retiniens, etc. 

L'authentiflcation a pour objectif de verifier l'identite des personnes en communication ou 
des processus rempla^ant ces personnes. Plusieurs solutions simples sont mises en oeuvre 
pour cela, comme l'utilisation d'un identiflcateur (login) et d'un mot de passe (password), 
d'une methode de defl fondee sur une fonction cryptographique et d'un secret partage. 
L'authentiflcation peut s'effectuer par un numero d' identification personnel, comme le 
numero inscrit dans une carte a puce, ou code PIN (Personal Identification Number). 

Des techniques d' authentication beaucoup plus sophistiquees, comme la verification 
d'une identite par les empreintes digitales ou retiniennes, se sont developpees de fa^on 
industrielle au debut des annees 2000. Les mecanismes permettant cette verification sont 
toutefois assez complexes et ne permettent cette solution pour verifier l'identite d'un 
individu que dans des contextes particuliers. 

L'authentiflcation peut etre simple ou mutuelle. Dans le cadre d'une communication tele- 
phonique, une authentication mutuelle est conseillee. Elle consiste essentiellement a 
comparer les donnees provenant de l'utilisateur qui se connecte a des informations stockees 
dans un site protege. Les attaques sur les sites memorisant les mots de passe representent 
une part importante du piratage. 

La confldentialite designe la garantie que les donnees echangees, les paroles telephoni- 
ques, ne sont comprehensibles que par les deux entites qui partagent un meme secret. 
Cette propriete implique la mise en oeuvre d'algorithmes de chiffrement en mode flux, 
c'est-a-dire octet par octet, ou en mode bloc, par exemple par serie de 8 octets. 

Les algorithmes de chiffrement permettent de transformer un message ecrit en clair en un 
message chiffre, appele cryptogramme. Cette transformation se fonde sur une ou 
plusieurs cles. Le chiffrement le plus simple est celui ou une cle unique et secrete est 
partagee par les seuls emetteur et recepteur. 
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Les systemes a cles secretes sont caracterises par une transformation/et une transforma- 
tion inverse/ - 1 , qui s'effectuent a l'aide de la meme cle. C'est la raison pour laquelle on 
appelle ce systeme « a chiffrement symetrique ». 

Les algorithmes de chiffrement a cle publique sont asymetriques. Le destinataire est le 
seul a connaitre la cle de dechiffrement. La securite s'en trouve accrue puisque meme 
l'emetteur ne connait pas cette cle. L'algorithme le plus classique et le plus utilise est 
RSA (Rivest, Shamir, Adleman), qui utilise la quasi-impossibilite d'effectuer la fonction 
d' inversion d'une fonction puissance. 

Les infrastructures de securite 

Des mecanismes tels que la confidentialite ou 1' integrite des donnees peuvent etre 
supportes a differents niveaux de 1' architecture et sur les differents tron^ons, ou arcs, qui 
composent le reseau. La gestion des cles de chiffrement peut etre, par exemple, realisee 
manuellement. 

L' identification, l'authentification, la non-repudiation et les autorisations sont des proce- 
dures mises en ceuvre dans le reseau d'acces, le reseau de transport IP et le reseau de 
destination, un intranet, par exemple. Ces services peuvent egalement etre offerts au 
niveau applicatif . 

Schematiquement, les infrastructures de securite des reseaux peuvent etre classees en 
cinq categories : 

• Chiffrement au niveau physique. Dans la cryptographie optique (PMD), le saut de 
frequences pseudo-aleatoire ou le chiffrement du flux d' octets (une methode couramment 
deploy ee par les banques), les cles sont distributes manuellement. 

• Confidentialite, integrite de donnees, signature de trames MAC. La distribution des 
cles est realisee dans un plan particulier, decrit par la norme IEEE 802. lx. Dans ce cas, 
on introduit la notion de controle d'acces au reseau LAN. C'est une notion juridique 
importante, dont le role est d'interdire le transport des informations a des individus non 
authentifies, et done potentiellement dangereux. 

• Confidentialite, integrite des donnees, signature des paquets IP ou TCP. C'est typique- 
ment la technologie IPsec en mode tunnel. Un paquet IP chiffre et signe est encapsule 
dans un paquet IP non protege. En effet, le routage a travers Internet implique 1' analyse 
de l'en-tete IP par les passerelles traversees. IPsec cree un tunnel securise entre le 
reseau d'acces et le domaine du fournisseur de services. On peut deploy er une gestion 
manuelle des cles ou des protocoles de distribution automatises, tels que ISAKMP 
(Internet Security Association and Key Management Protocol). La philosophic de ce 
protocole s'appuie sur la libre utilisation du reseau d'acces, qui ne va pas sans soulever 
des problemes juridiques. Par exemple, si des utilisateurs mal intentionnes protegent 
leurs echanges telephoniques, il est impossible aux reseaux traverses de detecter leur 
complicite dans le transport d' informations illegales. 
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• Insertion d'une couche de securite additive. Le protocole SSL (Secure Sockets Layer) 
fonde sur un chiffrement asymetrique assure la protection d' applications telles que la 
navigation Web ou la telephonie IP. SSL realise generalement une simple authentifica- 
tion entre serveur et client et negocie un secret partage (Master Secret), a partir duquel 
sont derivees les cles de chiffrement utilisees par 1'algorithme de chiffrement negocie 
entre les deux parties. Une fois le tunnel securise etabli, le client s'authentifie a l'aide 
d'un login et d'un mot de passe. II obtient alors une identite temporaire associee a un 
simple cookie. 

La securite dans la telephonie par Wi-Fi 

Pour securiser une communication telephonique dans un reseau sans fil, il faut doter 
l'environnement d'un certain nombre de fonctions, qui peuvent etre prises en charge soit 
par 1' infrastructure achetee pour realiser le reseau lui-meme, soit par de nouveaux 
elements de reseau a aj outer. 

De fagon plus precise, il faut intervenir aupres de quatre grands types d' elements 
d' infrastructure, 1' infrastructure qui permet l'authentification des clients et des equipe- 
ments de reseau, le materiel et le logiciel necessaires pour realiser la securite sur l'inter- 
face radio, les elements de reseau necessaires pour fUtrer les paquets et detecter les atta- 
ques et enfin les machines necessaires pour gerer les acces distants lorsque les 
utilisateurs se deplacent : 

• Infrastructure d'authentification. La norme IEEE 802. lx recommande 1' usage de 
serveurs RADIUS (Remote Authentication Dial-In User Server). L'authentification 
peut etre realisee par un serveur situe dans le domaine visite ou a l'exterieur de ce 
dernier. Cette architecture etablit un cercle de confiance, grace auquel un message 
d'authentification est relay e par plusieurs serveurs lies les uns aux autres par des asso- 
ciations de securite. 

• Securite radio. La securite radio vise a assurer la confidentialite, l'integrite et la signa- 
ture des paquets. Ces services sont delivres par des protocoles tels que WEP (Wired 
Equivalent Privacy), TKIP (Temporal Key Integrity Protocol) ou CCMP (Counter with 
CBC MAC Protocol), normalises par le comite IEEE 802. lis utilisent des cles 
deduites d'une cle maitre au terme de la procedure d'authentification. 

• Filtrage des paquets. La fiabilite de cette operation repose sur la signature des paquets 
a l'aide des cles deduites de l'authentification. Grace a ce mecanisme, les trames qui 
penetrent dans le systeme de distribution sont sures (pas de risque de spoofing). Des 
systemes de filtrage (point d' acces ou portail) gerent les privileges des paquets IP 
(destruction des paquets illicites) et permettent de realiser et de facturer des services de 
QoS (Quality of Service). 

• Acces aux services distants (roaming). L' acces a des services distants peut etre designe 
de fa^on generique sous 1' appellation de services VPN (Virtual Private Network). Par 
exemple, on peut mettre en oeuvre des liens securises interdomaines a l'aide des proto- 
coles IPsec ou SSL. 
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Conclusion 



Dans ce chapitre nous avons introduit les differentes architectures de reseaux qui peuvent 
etre utilisees pour transporter de la telephonie sur IP. 

Nous nous sommes interesses aux reseaux terrestres, en commen^ant par les reseaux 
d'entreprise de type Ethernet puis les reseaux d'operateur de type Relais de trames et 
ATM. Ces reseaux doivent etre batis pour introduire de la qualite de service. 

Nous avons detaille les environnements hertziens et decrit des solutions a deployer pour 
realiser de la TolP dans les reseaux Wi-Fi et WiMax. II est a noter que realiser de la tele- 
phonie sur Wi-Fi est plus complexe que sur WiMax, qui possede des classes de service 
permettant de prendre en charge directement la telephonie sur IP. 

En fin de chapitre, nous avons aborde la securite de la TolP. En fait, la securite de la TolP 
n'est pas vraiment differente de la securite des applications Internet en general. L' aspect 
temps reel est evidemment important puisqu'un deni de service, par exemple, ne permet 
plus le temps reel et fait tomber 1' application de telephonie plus facilement qu'une autre 
application. 

Globalement, on peut conclure que la TolP est une application difficile a mettre en place 
et que les architectures necessaires demandent a etre bien con^ues pour que la qualite de 
service soit obtenue a un cout tres bas. 

Le succes des reseaux DiffServ en entreprise en est une parfaite illustration. En utilisant 
des routeurs DiffServ, pas tellement plus chers que des routeurs classiques, il est assez 
simple d'obtenir de la qualite dans un environnement d'entreprise. 

En ce qui concerne les reseaux d'operateurs, la solution statistique apportee par DiffServ 
n'est plus forcement acceptable. Si tous les clients se mettent a telephoner a la suite d'un 
sinistre important, les flots de paquets de parole peuvent devenir trop importants par 
rapport a 1' infrastructure prevue. Ce que Ton peut faire dans une entreprise, dans laquelle 
le nombre d' employes est limite, ne peut etre reproduit lorsque plusieurs centaines de 
milliers, voire de millions d'utilisateurs peuvent se connecter simultanement. Dans ce 
cas, nous avons vu que les solutions consistaient a utiliser le relais de trames ou la 
version AAL2 de 1' ATM, qui permettent d'optimiser les ressources du reseau. 
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De la theorie a la pratique, il y a parfois des ecarts considerables. L'objectif de cette 
partie est de proposer un panorama assez large des applications pratiques de la tele- 
phonie sur IP. 

Les quatre premiers chapitres s'interessent aux softphones grand public. Parce qu'il 
nous paraissait difficile de les ignorer, compte tenu de leur succes, nous avons fait le 
choix d' analyser les tendances actuelles du marche, meme si, bien souvent, elles ne se 
conferment pas au modele theorique expose dans la premiere partie. Car souvent, des 
acteurs de renom, choisissent d'utiliser une technologie proprietaire. Le logiciel ainsi 
con^u s'appuie sur la notoriete de ces acteurs pour isoler ses clients au sein de son 
reseau, a 1' exclusion de tout autre reseau concurrent. 

Les softphones que nous presentons ne sont pas forcement dedies a la telephonie et ont 
parfois davantage vocation a servir de messagerie instantanee que de telephone. Mais 
la convergence des donnees vers un reseau entierement fonde sur le protocole IP 
s'accelere, et les outils de communication tendent a s'uniformiser pour s'imposer. 
Dans la mesure ou les softphones sont les reflets de cette tendance, nous avons privilegie 
une presentation generale de cette thematique, en nous penchant sur des softphones bien 
connus afln de les analyser, meme si la ToIP n'est parfois que le pendant de ces logiciels. 

Le chapitre 8 introduit la problematique des softphones de maniere generale. Nous 
detaillons les services que les softphones sont en mesure de fournir en plus de la ToIP 
et evoquons quelques offres du marche. 

Le chapitre 9 explore les caracteristiques de Skype, le softphone grand public le plus 
celebre. Nous essayons de comprendre les raisons de ce phenomene, qui a ete le 
premier a percer veritablement, generant un vif interet du public et une emulation 
importante parmi les principaux acteurs d' Internet. 

Le chapitre 10 se penche sur les caracteristiques des softphones WLM de Microsoft et 
Yahoo! Messenger de Yahoo!. Conscients du potentiel des services de telephonie, 
Microsoft comme Yahoo! ont tout naturellement fait evoluer leur logiciel de message- 
rie instantanee en softphone. Nous detaillons les principales fonctions de ces logiciels. 

Le chapitre 1 1 est consacre a la plate-forme Jabber et au softphone GTalk de Google. 
La encore, c'est la messagerie qui sert d'appui au service de telephonie. Nous 
detaillons les caracteristiques principales de la plate-forme et montrons comment cette 



approche, en suivant la normalisation et en cherchant a la faire evoluer, se distingue 
remarquablement de ces concurrentes. 

Les deux chapitres suivants analysent des aspects annexes de la telephonie sur IP, qui 
sont des champs d' application preponderants aujourd'hui. 

Le chapitre 12 presente un PBX d'un genre nouveau, Asterisk, solution logicielle gratuite 
(libre sous licence GPL), ouverte et innovante. Ce programme constitue une solution de 
rechange aux traditionnels PABX physiques d'entreprise, lesquels sont souvent des enti- 
tes particulierement fermees, complexes et onereuses. Asterisk fournit un niveau de 
service et de fiabilite comparable, sans investissement prealable. Nous montrons 
comment ce logiciel peut revolutionner la telephonie d'entreprise et pourquoi il peut 
aussi s'introduire chez les particuliers. 

Le chapitre 13 explique comment les operateurs de ToIP, ainsi que les FAI, qui se posi- 
tionnent de plus en plus en operateurs telephoniques, peuvent offrir leurs services de tele- 
phonie a leurs clients. Nous indiquons les differents reseaux d'acces deployes et leurs 
caracteristiques principales. 

Le dernier chapitre de cette partie se penche sur une difficulte d' application de la ToIP 
dans les reseaux : l'adaptabilite des flux conjointement a d'autres fonctionnalites. 

Le chapitre 14 examine un probleme delicat et recurrent de la ToIP, qui reside dans la 
traversee des reseaux deployant du NAT ou se situant derriere un pare-feu. Ces deux 
elements d' usage relativement courants posent probleme, et nous indiquons les techniques 
et protocoles qui permettent de les contourner. 
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Le temps est-il revolu ou Ton decrochait son telephone pour appeler ? Avec un ordinateur 
connecte a Internet, il sufflt d'un microcasque pour telephoner a moindre cout, parfois 
meme gratuitement, avec une qualite audio potentiellement superieure a celle de la tele- 
phonie traditionnelle et en disposant de fonctionnalites infiniment plus evoluees. C'est 
devenu possible grace aux logiciels de telephonie sur IP, appeles softphones. Les plus 
grands editeurs de logiciels se livrent une bataille acharnee pour imposer le leur. 

Bien des personnes sont toutefois reticentes a l'idee d'utiliser les fonctionnalites 
evoluees de leur ordinateur, mefiantes face aux mysteres de rinformatique et parfois 
craintives devant les aleas de leur connexion Internet. Pour telephoner par le biais d'un 
softphone, il faut d'abord allumer son ordinateur, verifier que la connexion Internet est 
fonctionnelle, lancer le softphone et enfin composer le numero de son correspondant. 
Mieux vaut ne pas etre presse pour communiquer de cette fa^on ! A premiere vue, on n'y 
trouve ni la modernite technologique, ni le confort d' utilisation, ni meme l'interet. 

La difference est qu'ici la communication n'est pas exactement celle que Ton connait. 
II s'agit d'un nouvel usage, plus riche et fondamentalement different, de la telephonie. 
Ce nouvel usage s'appuie sur le constat que le developpement des technologies reseau et 
des offres des fournisseurs d'acces accroit sans cesse le nombre de personnes connectees 
en permanence, ou presque, au reseau Internet. Cette masse deja consequente d'utilisa- 
teurs est de plus en plus rodee aux technologies reseau. A partir du moment ou les inter- 
nautes disposent d'une connexion a Internet permanente, il n'est pas plus difficile de 
composer un numero de telephone sur un ordinateur que sur un telephone. 

Avec les nouveaux services qu'offre le logiciel de telephonie, il devient possible d'ajou- 
ter de la video a la voix, d'etablir des conferences avec plus de deux intervenants, 
d' envoy er des photos de vacances ou des documents de travail en meme temps que Ton 
parle a son interlocuteur, de gerer un repertoire virtuel avec plusieurs dizaines, voire 
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centaines de contacts. Le tout gratuitement ou a moindre cout, sur un unique support, 
l'ordinateur, et avec un logiciel convivial, qui permet de communiquer indifferemment 
avec d'autres ordinateurs ou avec des telephones traditionnels. Le marche potentiel de ce 
nouvel usage est gigantesque. 

Parmi les pretendants au titre, Skype a lance la marche et s'est rapidement bati une 
renommee de leader. Son succes a ouvert les portes a la concurrence. Sur les traces du 
fameux logiciel, des societes parmi les plus importantes d' Internet ont lance leur propre 
logiciel de telephonie sur softphone, aux fonctionnalites tres analogues, tels Google, 
Yahoo ! et Microsoft. 

Ce chapitre propose un tour d' horizon des principales offres existantes et a venir. 

Introduction aux softphones 

La telephonie sur softphone presente des avantages indeniables sur la telephonie par 
ADSL, et ce pour les raisons suivantes : 

• En moyenne, moins d'un tiers des abonnes ADSL disposent de la telephonie dans leur 
forfait. Compte tenu de la progression du degroupage, ce nombre devrait augmenter, 
mais ceux qui n'en beneficient pas resteront tout de meme majoritaires et devraient 
etre interesses par les services des softphones. 

• Propre au reseau Internet, le service de presence permet aux utilisateurs de connaitre 
en permanence la disponibilite de leur interlocuteur. 

• Avec l'abonnement ADSL, une fois le fournisseur d'acces choisi, il est bien difficile 
d'en changer, tant les delais et les couts sont importants. Avec les softphones, par 
ailleurs souvent moins chers que 1' ADSL, on ne rencontre pas de tels problemes. 

• Tous les medias, audio, video, textes et applicatifs, peuvent transiter sur un meme 
support, alors que la visiophonie reste marginale dans le reseau telephonique tradi- 
tionnel. 

• L'utilisateur devient nomade puisque les connexions IP sont facilement disponibles 
partout dans le monde, et aux memes couts. 

Les services proposes 

Les logiciels de telephonie sur IP visent avant tout a se demarquer des autres offres de 
telephonie en prenant appui sur des services ay ant deja seduit les internautes. Leur prin- 
cipale cible est la messagerie instantanee, un service a la mode, qui s'est d'abord impose 
chez les plus jeunes, avant de s'etendre a une utilisation beaucoup plus large. 

La telephonie grand public n'a pas toujours ete le cceur de cible des acteurs du monde des 
softphones. Windows Live Messenger, de Microsoft, et le logiciel de Yahoo! n'avaient 
pas pour vocation initiale de faire de la telephonie sur IP, mais simplement de la messa- 
gerie instantanee. A l'inverse, Skype se cantonnait a la telephonie sur IP. Aujourd'hui, 
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tous ces acteurs proposent des fonctionnalites completes, qui englobent la telephonie au 
travers de services complementaires. 

La plupart de ces logiciels proposent des solutions pour telephoner sur Internet, mais 
aussi pour appeler des telephones fixes ou des mobiles, faire de la videoconference, 
partager des fichiers et de la musique et utiliser une messagerie instantanee. Globale- 
ment, la communication s'enrichit et offre de multiples facettes complementaires. C'est 
ce qu'on appelle la convergence des services. 



La telephonie 

Le debit requis pour la telephonie sur IP est tres faible pour une qualite audio satisfai- 
sante. En outre, les codecs utilises par les logiciels de telephonie sont souvent meilleurs 
que ceux utilises dans la telephonie traditionnelle. 

Le service de telephonie se decline sous deux formes. Une offre gratuite, purement 
Internet, et une offre payante, qui permet la convergence avec les reseaux telephoniques 
traditionnels. 

L'offre gratuite 

L' offre gratuite ne permet aux utilisateurs du logiciel que de communiquer entre eux. 
II s'agit d'une communication purement IP, qui sollicite exclusivement le reseau Internet, 
comme l'illustre la figure 8.1. 

Figure 8.1 

Le modele de telephonie tout-IP 

Appelant 




Appele 



Ce service est systematiquement propose gratuitement dans toutes les off res. La gratuite 
est justifiee puisque le cout de connexion au reseau IP est directement imputable a l'inter- 
naute, lequel s'acquitte d'une somme le plus souvent forfaitaire pour disposer d'une 
connexion Internet. La communication ne requiert done pas de surcout en soi. 
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Loffre payante 

L'offre payante met en relation un utilisateur utilisant un softphone avec un utilisateur du 
reseau de telephonie traditionnel. Les utilisateurs de softphone ne sont done pas confines 
a des communications entre internautes mais encourages a acheter des credits leur 
permettant d'appeler les telephones traditionnels. 

Ce sont done a la fois le reseau Internet et le reseau telephonique commute qui sont utili- 
ses dans ce mode de communication. Le service n'est plus gratuit puisque le reseau RTC 
est generalement facture a 1' usage et non forfaitairement. Grace a ces credits, les utilisa- 
teurs peuvent communiquer partout dans le monde, a des tarifs tres avantageux, une 
bonne partie de la communication transitant sur le reseau IP, y compris la partie qui relit 
l'abonne appelant a son operateur (voir figure 8.2). 

Figure 8.2 Appe|ant 

Le modele de 
telephonie IP/RTC 




Internet 



-t 





Passerelle 

Appele 

Pour rendre la communication possible, une passerelle est necessaire arm de transformer 
les flux IP en flux RTC, et reciproquement, car les protocoles de signalisation et de transport 
ne sont pas les memes dans les deux mondes. 

L' appelant exploite le reseau IP de son fournisseur d'acces, puis passe par la passerelle 
pour communiquer avec des utilisateurs du reseau telephonique RTC. Plus cette passe- 
relle est proche de 1' appele, moins la communication est onereuse. 

La liaison entre 1' appelant et 1' appele ne peut etre realisee pratiquement que sur Internet, 
sauf pour la liaison terminale avec l'appele, e'est-a-dire les dernieres centaines de metres 
qui le relient au commutateur RTC le plus proche. Cette liaison est la seule facturation 
reelle a considerer, car en utilisant le reseau IP prioritairement, il n'est plus necessaire de 
sous-louer aux operateurs de telephonie leur reseau pour transporter les flux de parole 
telephonique, ce qui allege considerablement la facturation des appels. 

Globalement, la facturation se fait soit au forfait, incluant un grand nombre de pays sans 
limitation de duree, soit, selon le pays de la personne appelee, a des tarifs variables en 
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fonction des solutions utilisees, mais souvent moins chers que ceux proposes par les 
operateurs de telephonie ou les fournisseurs d'acces a Internet. 

Liste de contacts, presence et disponibilite 

Arm de simplifier la gestion des contacts, les logiciels de TolP offrent la possibilite de 
lister l'ensemble de ses contacts, c'est-a-dire d'avoir un repertoire organise en groupes de 
personnes (amis, famille, relations professionnelles, etc.). Cela permet de disposer d'un 
repertoire numerique, comportant numeros de telephones portables et fixes, professionnels 
et personnels, adresses de messagerie, sites Internet, blogs, etc. 

Cette liste simplifie les appels puisqu'il n'est pas necessaire de connaitre les identifiants 
ou les numeros d'appel d'un contact. Tous sont virtuellement visibles et joignables par 
simple clic a partir de leur veritable nom ou du pseudonyme qu'ils se donnent. 

A cette liste est associe un indicateur de presence et de statut, qui permet d' informer les 
autres contacts de la disponibilite de chaque interlocuteur. Cet indicateur permet de 
savoir si un correspondant est joignable, c'est-a-dire s'il a connecte son logiciel de tele- 
phonie au reseau, et s'il est disponible ou occupe. 

Le statut peut etre gere manuellement ou automatiquement. II est gere manuellement 
pour indiquer explicitement qu'une activite est en cours chez le correspondant. Par exem- 
ple, un utilisateur informe ses contacts qu'il est au telephone et ne souhaite pas etre 
contacte. II peut aussi etre gere automatiquement. Par exemple, si le logiciel ne releve 
aucune activite sur le poste de travail d'un utilisateur, il peut modifier son statut pour 
notifier cette inactivite. Les gestions manuelles et automatiques peuvent se combiner. 

Messagerie instantanee 

La messagerie instantanee, aussi appelee IM (Instant Messaging) ou IMP (Instant Messa- 
ging and Presence) ou plus couramment chat, est un mode de communication textuel et 
interactif qui connait un enorme succes. C'est un peu l'art de discuter avec plusieurs 
personnes a la fois sur des sujets d'importance variable, tout en pouvant effectuer une 
autre activite en parallele, comme ecouter de la musique ou passer un appel telephonique. 

Le premier systeme de messagerie a ete 1'IRC (Internet Chat Relay). Con^u par Jarkko 
Oikarinen et Darren Reed, il a ete standardise en mai 1993 par la RFC 1459, remplacee 
ensuite par les RFC 2810 a 2813. Depuis, des efforts considerables ont ete apportes a 
l'ergonomie et aux services. L'IRC n'en reste pas moins toujours aussi populaire 
aujourd'hui, en parallele des systemes de messagerie instantanee. 

La messagerie instantanee n'a en elle-meme aucun rapport avec la telephonie sur Inter- 
net. C'est toutefois un outil complementaire en ce qu'elle permet une certaine reactivite, 
voire interactivite, avec l'avantage de communiquer de maniere moins intrusive que la 
telephonie. 
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Le SPAM 

On note cependant un probleme persistant avec la messagerie instantanee, que partagent 
les differents softphones : le SPAM, c'est-a-dire des messages non sollicites pouvant 
contenir des virus. Par le biais du reseau IP, le monde entier devient joignable a moindre 
cout, ce qui incite les spammeurs a utiliser ce canal. 

On distingue deux types de SPAM : 

• Le Call Spam, qui designe des tentatives d'appels en masse. Lorsque le correspondant 
accepte l'appel, le spammer lui diffuse immediatement un message audio, a caractere 
commercial le plus souvent. C'est l'equivalent du telemarketing massif. 

• Le SPIM (SPam over Instant Messaging), c'est-a-dire le Spam par messagerie instan- 
tanee. Dans ce type de SPAM, une publicite est envoyee soit par messagerie instantanee, 
soit en annon^ant un sujet pour un pretendu appel. Dans ce dernier cas, lorsque 
l'appele lit le sujet de l'appel, le message publicitaire est passe, que l'appele reponde 
ou non a l'appel. C'est l'equivalent du Spam par e-mail. 

Lorsqu'on sait qu'en utilisant Skype, une simple recherche sur un prenom renvoie la liste 
des personnes qui portent ce prenom et leur adresse e-mail associee, on comprend pour- 
quoi le SPIM peut se repandre aussi facilement et rapidement dans les reseaux. C'est l'un 
des risques inherents a la facilite de mise en relation, pronee par tous les softphones. 

Les parades possibles consistent a limiter les contacts en definissant une liste de contacts 
prohibes au fur et a mesure que des spammeurs sont detectes (liste noire) ou en utilisant 
des listes de contacts autorises (liste blanche). Un filtrage des contenus de flux s'avere 
difficilement praticable, en particulier pour le Call Spam. 

Video et transfert de fichiers 

Les softphones permettent de superposer au son telephonique une image capturee par 
une webcam. Les communications sont ainsi plus riches et se pretent parfaitement a un 
cadre familial. 

Le transfert de fichiers s'effectue sans passer par des serveurs centralises, mais directe- 
ment d'un poste a 1' autre. Cela permet de ne sollicker que les machines qui participent 
effectivement au transfert, et ainsi de ne pas saturer les serveurs centraux. 

Dans ce mode de communication, l'interactivite est perdue, contrairement a la telepho- 
nie, la video ou la messagerie instantanee. Mais cette possibilite se combine souvent aux 
precedentes pour completer et enrichir une communication avec differents documents, 
qu'il s'agisse de documents de travail ou de fichiers multimedias. 

Le transfert de fichiers se fait de maniere non bloquante, en tache de fond, laissant la 
place a toute autre forme de communication, messagerie instantanee ou communication 
audio/video. 
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Les softphones en entreprise 

Bien souvent, les installations de softphones se font par les utilisateurs eux-memes, sans 
controle des administrateurs reseau de 1' entreprise, ce qui ne va pas sans poser probleme. 
D'autant que ces derniers sont parfois depourvus des moyens d' assurer une gestion effl- 
cace de ces logiciels. Skype comme WLM utilisent des protocoles proprietaires difflciles 
a flltrer et qui contournent les politiques de securite de 1' entreprise en se faisant passer 
pour des flux licites. 

Les risques sont bien reels, a commencer par les attaques par virus ou chevaux de Troie. 
II n'en reste pas moins vrai que tous les logiciels sont potentiellement sujets a ces infec- 
tions. Ce qui pose probleme ici, c'est surtout l'opacite des protocoles utilises et la volonte 
de s'integrer dans un reseau en contournant les politiques de securite definies par 1' entre- 
prise. Les deploiements se font done de maniere anarchique, sans que quiconque maitrise 
les risques de detournement d'appel ou d'ecoute passive des communications. 

Reste pour les administrateurs a utiliser des outils de fUtrage specifiques a ces protocoles, 
qui sont nombreux, mais pour la majorite pay ants. L' autre solution, beaucoup plus radicale, 
mais souvent utilisee, consiste a ne donner aucun droit d'administrateur aux utilisateurs, de 
maniere a controler toute nouvelle installation logicielle. 



Les autres softphones 

Les chapitres suivants de l'ouvrage presentent en detail les softphones les plus reputes. 
Nous ne mentionnons ici que les principales caracteristiques de quelques autres logiciels 
afin d'offrir un panorama assez large des offres actuelles. 

WengoPhone 

Wengo est une societe franchise specialisee dans les services de TolP, qui s'est recentree, 
depuis 2007, sur les services d'aide entre particuliers par telephone. Filiale de l'operateur 
Neuf Cegetel, 1' entreprise s'est fait une place sur le marche des solutions de telephonie 
en proposant un logiciel complet et performant, WengoPhone. 

La societe ne dispose pas d'une force de frappe semblable a celle de ces concurrents, 
Microsoft ou Yahoo!. Elle ressemble un peu a Skype a ses debuts, pour qui le bouche-a- 
oreille a remplace le marketing direct. Pour s'imposer, WengoPhone se presente comme 
un outil federateur face aux logiciels proprietaires. 

L'un des atouts innovants de WengoPhone est l'ouverture de son code source. Chacun est 
libre de consulter 1' implementation du logiciel et d'y apporter sa contribution dans une 
version particuliere du logiciel, appelee WengoPhoneNG. 

WengoPhone utilise le protocole SIP pour la signalisation d'appel, respectant ainsi les 
standards protocolaires, ce dont peu d' autres logiciels peuvent se targuer. 
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Le logiciel peut etre installe sur la plupart des systemes d' exploitation existants : MacOS 
X, Linux (multiplate-forme), Windows 2000, XP ou Vista et Windows Mobile 5 et 6 pour 
Pocket PC et SmartPhone. 

Telechargeables sur le site de l'editeur (www.wengophone.fr/index.php), les differentes versions 
du logiciel permettent d'adresser un maximum d'utilisateurs potentiels. Nous nous inte- 
ressons dans ce qui suit a la version Windows. 

Une fois le programme d'une quinzaine de megaoctets telecharge et lance, il est neces- 
saire de s'authentifler avec un compte Wengo. La creation d'un compte est extremement 
rapide. Elle ne necessite que trois informations de base : un identiflant, un mot de passe 
et une adresse e-mail (pour activer le compte). 

Pour effectuer un premier appel de test, permettant de calibrer son materiel audio, il suffit 
de composer le 333 et de se laisser guider. 

Peu de fonctionnalites de personnalisation sont disponibles, mais signalons tout de meme 
la possibilite de dialoguer avec les logiciels de messagerie concurrents. 

Dialoguer entre logiciels concurrents 

WengoPhone est le premier logiciel a proposer une solution de telephonie avec les services 
associes, tout en assurant la compatibilite de sa messagerie instantanee avec les logiciels 
concurrents. 

WengoPhone gere les communications textuelles avec des utilisateurs appartenant aux 
reseaux de messagerie les plus utilises : WLM/MSN, Yahoo IMessenger, AIM/ICQ, 
Jabber et GoogleTalk. 



Figure 8.3 
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Pour aj outer un contact appartenant a Tun de ces reseaux, il suffit de selectionner les 
menus Outils et Compte de messagerie (ou Outils, Configuration et Comptes). La fene- 
tre illustree a la figure 8.3 s'afflche alors. Les boutons situes au bas de la fenetre 
permettent d'ajouter des contacts en mentionnant leur identifiant et le reseau auquel ils 
appartiennent. 

Le plus etonnant est que cette compatibilite ne s'appuie sur aucun partenariat. Protegeant 
jalousement leur pre carre, les autres editeurs de logiciels sont depourvus de cette possi- 
bility de converser independamment du reseau auquel appartiennent les contacts et ne 
diffusent generalement pas leur code source. 

Seule la reglementation sur le droit a l'interoperabilite a permis cette fonctionnalite. 
Pour cela, Wengo a du analyser en profondeur les communications reseau de chacun 
des logiciels tiers, en reproduisant le schema protocolaire des communications. 
Malheureusement, ni 1' audio ni la video n'offrent encore cette souplesse. De plus, 
1' analyse fastidieuse des donnees peut etre remise en cause chaque fois qu'un editeur 
modifie ses couches protocolaires. En outre, le logiciel Skype a echappe a ces ana- 
lyses. 

Le logiciel WengoPhone est egalement fourni en marque blanche du fournisseur d'acces 
et operateur telephonique Neuf Cegetel pour son offre de telephonie mobile, c'est-a-dire 
sans que le nom du logiciel ne soit mentionne dans la commercialisation des produits. 
C'est ainsi que le cadre du projet Beautifull Phone, destine a promouvoir la convergence 
des communications fixes et mobiles, le telephone Twin, embarque une version du logiciel 
WengoPhone. 

Le combine hybride propose par de Neuf Cegetel, a la fois GSM et Wi-Fi, tente priori- 
tairement de se raccorder au reseau domestique IP de 1' operateur, en utilisant la tech- 
nologie Wi-Fi et la signalisation SIP. Ainsi, le combine va chercher par Wi-Fi 
n'importe quel reseau IP sur lequel il est autorise a se connecter, par exemple celui 
d'un abonne de l'operateur ou plus generalement d'une zone dans laquelle l'operateur 
a conclu des accords. Si cette connexion est possible, la communication telephonique 
s'effectue en IP et est facturee aux conditions tarifaires de la ligne fixe de l'abonne, 
avec notamment, la gratuite vers les postes fixes partout en France, done d'une maniere 
tres avantageuse par rapport aux conditions tarifaires d'une ligne mobile. A defaut de 
connexion au reseau IP, le mobile Twin se connecte au reseau GSM, aux conditions 
tarifaires du contrat mobile. 

L' offre commerciale Unik de France Telecom propose un service equivalent. 

Avec quelques milliers d' inscriptions par jour, WengoPhone a beaucoup de chemin a 
parcourir pour rattraper les millions de telechargements de Skype. Mais, etant fonde sur 
des protocoles standardises, ouverts et compatibles avec les systemes de messagerie 
concurrents, WengoPhone possede des atouts indeniables, dont ne disposent pas toujours 
les logiciels concurrents. 
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Telephoner gratuitement d'un PC vers un telephone fixe 

Parmi les dizaines de sites qui proposent de telephoner gratuitement d'un PC vers des 
elephones fixes sur des dizaines de destinations, citons notamment les suivants : 

Netappel (www.netappel.fr) 

VoIPB us ter (www. voipbuster. com) 

VoIPStunt (www.voipstunt.com) 

VoIPCheap (www.voipcheap.com) 

VoIPDiscount (www. voipdiscount. com) 

InternetCall s (www. internetcalls. com) 

SIPDiscount (www.sipdiscount. com) 

En depit de la profusion de ces sites, ce modele ne semble guere viable a premiere vue. 
En realite, derriere tous ces sites se cache une seule et meme societe, Finarea S A, basee a 
Lugano en Suisse. La multiplicity des offres a pour unique objectif de rabattre de 
nouveaux clients vers cette societe. 

Multiplication des offres volatiles 

Creee en avril 2000, Finarea SA (www.finarea.ch) est specialise dans la telephonie discount 
et s'est fait connaitre par des tarifs ultra-agressifs, parfois difficilement rentables, mais 
progressivement revus a la hausse. 

Tous les logiciels proposes par Finarea reposent sur une offre d'appel generalement simi- 
laire : les communications sont offertes vers un grand nombre de destinations, quelle que 
soit la duree de la communication. La seule contrainte est que l'utilisateur qui ne detient 
qu'un credit nul ne dispose que d'une duree de communication de quelques minutes, le 
plus souvent deux. Au-dela de cette duree, l'appel se termine automatiquement. 

Si l'utilisateur credite son compte, ne serait-ce que de quelques euros, le credit n'est pas 
decrements pour les communications gratuites, et les communications n'ont plus aucune 
restriction de duree. En clair, le modele incite a acheter des credits, lesquels ne seront pas 
forcement utilises, mais donneront droit a des appels illimites. 

Les conditions d'utilisation sont moins claires quant a la liste des pays que Ton peut join- 
dre gratuitement. Le logiciel propose etant en version Beta, cette liste varie en perma- 
nence et n'est pas garantie. Autrement dit, un utilisateur peut s'acquitter d'un credit pour 
telephoner a un certain tarif vers une destination et decouvrir du jour au lendemain que le 
tarif a ete modifie sans preavis. 

La vigilance est done de mise, y compris pour la liste des destinations vers lesquelles les 
appels sont gratuits. Certains pays apparaissent, tandis que d'autres deviennent subite- 
ment payants. Petit a petit, et une fois le service connu, l'operateur change sa grille tari- 
faire pour faire place a des tarifs qui n'ont plus rien de gratuit. En attendant, un nouveau 
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service similaire ouvre sur un autre site, avec un nom different, mais une meme ergo- 
nomie du site et du logiciel, et une nouvelle offre tarifaire agressive est proposee. 

Signalons pour flnir que les credits ont une duree de vie limitee a quelques mois. Par 
consequent, 1' appelant doit les recharger regulierement pour pouvoir appeler « gratui- 
tement ». 

Les clients de messagerie Web 

Meebo (www.meebo.com) illustre le concept de messagerie multiprotocole sur le Web. Avec 
un simple navigateur, il est possible de se connecter simultanement sur ses comptes 
WLM, Yahoo!, Jabber/GoogleTalk et AIM/ICQ. 

En se connectant a la page d'accueil de Meebo, l'utilisateur est invite a saisir les identi- 
flants et mots de passe de tous les comptes de messagerie sur lesquels il souhaite se 
connecter. Une fois authentifie, il retrouve sur 1' interface de son navigateur 1' ensemble 
des contacts de ses differents comptes, et peut communiquer avec eux. En outre, il 
dispose de la possibilite de reorganiser la page en redimensionnant ou depla^ant les fene- 
tres de dialogue a sa guise. C'est la technologie Ajax (Asynchronous JavaScript and 
XML) qui permet cette liberte d' action. Ajax s'inscrit dans la mouvance de ce que Ton 
appelle le Web 2.0, exprimant une nouvelle forme d'ergonomie grace a laquelle les pages 
Web, en plus d'etre dynamiques, deviennent personnalisables, a la maniere de veritables 
applications. 

Ce service est limite a la messagerie, et il n'est pas possible d'effectuer des appels tele- 
phoniques ou des videoconferences ni d'echanger des fichiers. Meebo est du reste encore 
en version Beta, done en cours de developpement. 

La telephonie Free 

Comme bon nombre de ses concurrents, l'operateur Free, filiale du groupe Iliad, a deve- 
loppe une offre de telephonie fixe qui se base sur le protocole de signalisation SIP. Mais, 
contrairement a beaucoup d'autres, il ne s'est pas arrete la et a etendu son offre commer- 
ciale avec deux possibilites tres interessantes : 

• Le compte SIP : Free fournit a tous ses abonnes un login et un mot de passe associes a 
un compte SIP. Ce compte permet a l'abonne de se connecter en dehors de son domi- 
cile, a partir d'une simple connexion Internet, pour acceder aux memes services de 
telephonie et services que ceux auxquels il a acces de chez lui. Autrement dit, l'abonne 
n'a pas besoin d'etre chez lui pour profiter de la gratuite des appels en France et dans 
des dizaines de destinations dans le monde, ainsi que des conditions avantageuses de 
tarification de son forfait. II lui suffit de disposer, d'une part, d'une connexion a 
Internet et, d' autre part, d'un logiciel SIP correctement configure. 

• La Freephonie : la Freephonie propose une extension du domaine d'acces de l'utilisa- 
teur, de son domicile a un vaste reseau constitue de toutes les Freebox compatibles. 
Autrement dit, l'utilisateur qui est abonne chez Free et qui se deplace en dehors de sa 
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residence peut acceder a toutes les Freebox qui l'entourent, appartenant a d'autres 
abonnes. Bien sur, la connexion n'est accessible qu'a partir d'un compte prive. Done si 
les appels ne sont pas couverts par l'abonnement, ils seront naturellement factures a 
1' appelant, et non a celui qui laisse sa Freebox a disposition. 

La Freephonie etend les possibilites du compte SIP : alors qu'avec un compte SIP, il 
est necessaire d' avoir un acces Internet ouvert, le reseau Freephonie fournit a 
l'abonne un ensemble de points d' acces a Internet, qui peuvent etre securises et 
fermes pour les utilisateurs en general, mais seront accessibles et ouverts pour cet 
usage en particulier. 

Dans ce qui suit, nous allons decrire brievement la maniere d' acceder a ces deux services. 

Le compte SIP 

Pour acceder aux services telephoniques de Free a partir de n'importe quelle station (PC, 
MAC, PDA ou SmartPhone, comme 1'iPhone d' Apple), il est necessaire d'avoir un acces 
a Internet et un logiciel SIP configure avec ses parametres personnels. 

Pour connaitre ses parametres personnels, l'internaute doit se rendre dans son interface 
Web de gestion de compte, accessible a la page http://subscribe.free.fr/login/. Une fois son 
identification faite, l'internaute accede a sa console de gestion, lui permettant de gerer 
toutes les fonctionnalites de son compte. La section « Gestion de mon compte SIP » (voir 
figure 8.4) permet d'afflcher les parametres SIP de son compte. 



Figure 8.4 

Acces au compte SIP 
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En cliquant sur ce lien, on repere trois parametres importants (voir figure 8.5) : 

• L'identiflant du compte : e'est le numero de telephone de l'abonne, constitue de dix 
chiffres (identiques au parametre nomme Utilisateur). 

• Le mot de passe : constitue de dix caracteres au moins, il est laisse au libre choix de 
1' utilisateur. 

• Le domaine : son nom (freephonie.net) est celui du serveur de Free que l'abonne va 
sollicker pour l'etablissement de sa connexion. 
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On remarque egalement deux options : la premiere permet, lors de la reception d'appel, 
de faire sonner tout combine ou logiciel configure avec les parametres SIP precedents, ou 
bien (cas par defaut) de faire sonner le telephone relie a la Freebox ; la seconde permet 
d'activer ou de desactiver ce service. II est indispensable que cette case soit cochee pour 
que l'abonne puisse utiliser son compte SIP. Nous verrons a la section suivante l'utilite 
des certiflcats mentionnes en bas de la page de configuration. 

Une fois valide (par le biais du bouton Envoy er), le service est automatiquement et 
immediatement disponible. 



Figure 8.5 
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Pour y acceder, n'importe quel logiciel ou telephone compatible avec le protocole SIP 
convient, pourvu qu'il soit disponible sur sa plate-forme (PDA, SrnartPhone, portable ou 
ordinateur fixe). On pourra par exemple, choisir d' utiliser WengoPhone, SJphone, GoSIP 
(tous trois disponibles sous Windows, Mac, Linux et Windows Mobile), Xlite et Gizmo 
Project (tous deux disponibles sous Windows, Mac, Linux), Ekiga (Windows, Linux, BSD) 
et twinklephone (Linux), parmi les tres nombreux logiciels SIP disponibles gratuitement, 
generalement sous licence GPL. 

Pour acceder a son compte SIP et pouvoir telephoner librement, comme si on se trouvait 
chez soi, il suffit de configurer les parametres susmentionnes, a savoir l'identiflant et le 
mot de passe (prives) ainsi que le nom de dornaine et l'adresse du serveur proxy, pour 
lesquels on entrera dans les deux cas l'adresse freephonie.net. Ces parametres sont 
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generalement accessibles dans les options du logiciel. On evitera de modifier les parametres 
dont la fonction n'est pas clairement identifiee. 

Pour un exemple, reportez-vous a la section de configuration du logiciel XLite detaillee 
au chapitre 12, dedie au PBX Asterisk. 

Free a recemment developpe un logiciel permettant a tous les possesseurs d'un telephone 
iPhone d' Apple debloque de se connecter pour acceder a leur compte SIP de Free et de 
profiter des memes avantages. 

Ce logiciel est disponible a la page http://sip.free.fr. La demarche est analogue a celle decrite 
ici, si ce n'est qu'elle implique le telechargement du logiciel developpe par Free et speci- 
fique a la plate-forme de 1'iPhone. 

Le reseau Freephonie 

Le reseau Freephonie autorise l'abonne a se connecter sur n'importe quelle Freebox 
compatible (a partir des versions v5 ou HD) pour y etablir ses communications tele- 
phoniques. Seules les communications telephoniques sont possibles, a l'exclusion de tout 
autre service, comme la navigation sur Internet. Ces connexions pourraient en effet 
consommer une bande passante importante de l'abonne chez lequel on se connecte, au 
detriment de la qualite de la connexion de ce dernier. 

Pour cela, l'abonne doit telecharger et installer sur son terminal les certificats qui lui sont 
fournis tout en bas de la page de gestion du compte SIP que nous avons presentee prece- 
demment, avec le lien « Afficher les certificats pour votre Pocket PC/Smartphone » (voir 
figure 8.5). 

En cliquant sur ce lien, trois certificats sont disponibles (voir figure 8.6) : une clef privee, 
une clef publique et un certificat racine (dit root). 

Si le telechargement de ces fichiers ne pose pas le moindre probleme, leur installation 
requiert toutefois quelques manipulations. En fait, a l'origine, l'operateur Free commer- 
cialisait des telephones SIP preconfigures avec les parametres necessaires. Depuis peu, 
les parametres ont ete decryptes et diffuses sur Internet. La societe Free semble avoir 
encourage ce mouvement, en fournissant a chaque abonne les parametres prives de son 
compte (les certificats vus plus haut), mais sans toutefois documenter le moyen de les 
mettre en oeuvre. 

Voici la methode a suivre pour la generation et 1' installation de ces certificats. Cette 
demarche s'oriente, pour 1' exemple, vers un appareil (PDA ou SmartPhone) disposant du 
sy steme d' exploitation Windows Mobile 6, mais la methode est equivalente sous 
Symbian, si ce n'est que les menus different. 

La premiere etape consiste a sauvegarder ces clefs et certificats dans des fichiers textuels 
de son ordinateur. Avec un simple editeur de texte, comme Notepad, on recopie le 
contenu de chacune de ces deux clefs et du certificat dans un fichier (l'integralite, debu- 
tant et se terminant par les premiers et derniers tirets, sans y inserer d'espace en 
debut, ni fin de fichier). On nommera ces fichiers respectivement free_clef_priv.txt, 
free_clef_pub.txt et free_ certif__racine.txt. 
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AFFICHER LES CERTIFICATE POUR VOTRE ACCES SIR 



Vous trouverez ci-dessous les certificats destines a votre compte SIP permettant de 
configurer votre pocket PC GSM compatible SIP : 



Clef Privee : 

BEGIN RSA PRIVATE KEY 

b Z 1X1 2 9Bnr Z zkO ZE4KY+pI 3 S OoPPbRT W/LkP S j 1 3B4E 5 OamEUX+hbEFQ le vwvG 
wQ ABgYE AXtjtt SkJXHlUJrSt u8 /aRAGj GBr IeB 3yHgG9 GhBLc e vGGf 6mrj qBYorpTypLs 1 
ZT AeFroOvjOB AOMTMxMBQ IMTRaFroOnOB A2MTMxMBQ !MTRaHE4xC e AJBgNVB AYT Ak Z S 
MQ &wBQYB VQQIEwZGcitiEuY2UxB j AMBgNVB AcTB VBhcinl eM)Q OwCtfYD VQ QKEtoRGcjtlVL 
B AgTBkZyYW5 j ZTEOlQh-jGAllJEBxMFUGFyaXMxBT ALBgNVB AoT 7XAqIqBg6E +CMXqc 
vTELMAkGAlUEF 2inrcoaILNdws dpC4wSE 2 wco +bt Ekt f 7ft= 
ENB RSft PEIVftTE KEY 



Clef Publique : 



BEGIN CEETIEICftTE 

ICTICft j CCfflfeCCQCPCb 9 5 / 8o OPB ANBgkqhk±G9wOB ftQQE ftB ASMQswCQYB VQQGEtoJG 
V j EPl£ftOGA11JECBMGBjnJhbmNlMQ4\ *B ftYD VQQHEwVQYXJpc EENMAsGAlUECKUERnJl 
ZT AeFwfhiOB AOMTMxHDQ IMTRaFroOnOB A2MTMxMBQ lMTRa21E4xC e AJBgNVB AYT AkZ S 
P v8m5dp 6U5 VS j j i 7eBT j UOyBsnVaAt 6Ir vj dr xvhAgMB ftAEuBQYJKo ZlhvcNAQEE 
BQ ADgYE AXw5kJXMV3tu8 /aEAG j GBr IeB 3yHgG9 GhBLc e vGGf Gmcj qBYorpTypLs 1 
xOap 9dr dr gdBICUTleHQ Ast CaA6Ln/TMJi VaytomPdB wTluS lk/I EEq4Xk7 SsnpPu 
j UTy 7T /C GpPdVF f GqAXGq/jymkRf UBuHNYgp dpC4w«E 2uvcoeaJM= 
ENB CERTIFICATE 



Certiflcatrootfreephonie : 



BEGIN CERTIFICATE 

MUGmDCC AgGgAwIB AgTBkZyYWS j Z TELMAkGAlUEBxMFUGFyaXHscBT ALBgNVB AoT V 
B AYT AkZ SMQ SroBQYB VQQIEwZGcmFuY2 UxB j AMBgNVB AcTB VBhcinl eMQ OwCwYB VQQK 
FroRGciTiTELMAkGAlUET AyNBE eM j MOHVoXBTE 2MT AyMTE eM j MOHVoroPTELMAkGAlUE 
BMfCRIB AgTBkZyYWS j TELMAkGAlUEvcoMFUGFyaXMxBT ALBgNVB AoT ALBgNVB AoT 
n j E IuYIBCB +RnAK/utK+ Ztirej lekOWAupoQ 9x2 9ML SWlAboWT BqrYroP +GWJB 2yLb 
lui2Lq7ps S 3 5 Z JQp TELMAkGAlUEPwj 2 /PhZQp SI S + 5w/sqXy S ASaY+xHuP +g= 
ENB CERTIFICATE 



Figure 8.6 

Parametres du compte SIP 



La seconde etape consiste a installer OPENSSL et a l'utiliser pour la generation de certiflcats 
valides. OPENSSL peut etre telecharge, par exemple, a l'adresse http://www.slproweb.com/ 
products/Win320penSSL.html. Une fois installe, on se rend dans le repertoire que Ton a choisi 
durant 1' installation et qui contient 1' executable openssl.exe. On y deplace les trois 
flchiers textes precedemment crees. Puis, on lance le programme openssl.exe et, dans le 
terminal qui s'ouvre, on saisit les deux lignes suivantes : 

enc -d -base64 -in free_certif_racine.txt -out free_certif_racine.cer 

pkcsl2 -export-infree_clef_jmb.txt -inkey free_clefjpriv.txt -out free _certif.pfx 

La premiere encode simplement le fichier sur la base 64. Elle n'est parfois pas indispensable, 
et une simple modification de 1' extension .txt en .cer sur le fichier free_certif_racine 
sufflt sou vent, selon le systeme d' exploitation. 
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La ligne suivante genere, a partir de la clef publique et de la clef privee, un unique certi- 
ficat au format PKCS 12. Un mot de passe (optionnel) de son choix est requis lors de la 
creation de ce second certificat. II permet de securiser ce flchier en limitant son utilisation 
a son concepteur. 

Des lors, dans le meme repertoire que celui ou se trouve la commande openssl.exe et les 
flchiers free_clef_pub.txt et free_clef_priv.txt, nous trouvons le certificat genere, dont le 
nom a ete fixe a free_certif.pfx. 

La quatrieme etape consiste a deplacer les deux flchiers generes free_racine.cer et 
free_certif.pfx sur son PDA ou SmartPhone, et de les executer tous les deux en cliquant 
dessus. Le mot de passe, choisi precedemment, est requis lors de l'mstallation du flchier 
free_certif.pfx sur son terminal. Les deux installations doivent etre validees par un 
message de succes. 

La cinquieme etape consiste a regler les parametres de la connexion Wi-Fi. Pour cela, 
apres avoir active le Wi-Fi sur son terminal et selectionne un reseau dont le nom est Free- 
phonie, on selectionne les parametres de la connexion Wi-Fi. On y choisit une authenti- 
cation WPA et un cryptage TKIP et, sur la page de configuration d'authentification, on 
selectionne « Carte a puce ou certificat » comme type EAP. Puis, on clique sur le bouton 
Proprietes et, dans les certificats, on selectionne celui reference comme emis par Free par 
un clic prolonge permettant d'acceder aux proprietes de ce certificat. Dans la fenetre qui 
s'affiche, on note simplement le numero affiche sous la ligne « Octroy e a ». II est utile 
dans la derniere etape. On valide cette etape apres s'etre assure que le certificat Free est 
bien selectionne. 

La derniere etape consiste a valider la connexion sur le reseau Freephonie. Quelques 
secondes plus tard, une fenetre s'ouvre, sollicitant un nom d'utilisateur et un nom de 
domaine. On entre pour le premier le numero note precedemment, et on laisse vide le 
champ domaine. La connexion doit alors s'effectuer avec succes : l'utilisateur est 
connecte au reseau Freephonie. 

Le logiciel sofphone de son choix peut ensuite etre utilise, a condition de remplacer 
l'adresse du serveur proxy a contacter par l'adresse 172.17.20.241 (a la place de freepho- 
nie.net). On configure done son logiciel SIP avec pour parametres son identifiant, son 
mot de passe, le nom de domaine (freephonie.net) et l'adresse du proxy (172.17.20.241). 

Les certificats ainsi crees ont une duree de vie de deux mois. Passe ce delai, il faut repeter 
la procedure. Cette limitation permet de restreindre les possibilites d'abus et de fraude. 
Cette fonctionnalite offre a l'utilisateur beaucoup de souplesse dans son exploitation, 
mais elle demeure liee a un contrat d'abonnement prive avec le fournisseur d'acces selon 
lequel une diffusion de ces certificats au-dela des termes du contrat serait illegale. 

L'operateur Neuf Telecom utilise lui aussi le protocole SIP pour les connexions tele- 
phoniques de ses abonnes et leur permet de maniere semblable a Free de se connecter 
au reseau constitue de toutes les NeufBox des abonnes, ainsi que dans differents 
hotspots. 
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Conclusion 



Le telephone traditionnel a probablement encore une longue vie devant lui, mais les 
evolutions technologiques et les nouveaux usages des internautes jouent en la faveur du 
reseau IP. 

Pour simuler une utilisation conforme au traditionnel reseau RTC, certains services 
proposent d'utiliser un combine habituel en utilisant de maniere transparente le reseau IP. 
C'est le cas, par exemple, du service Jajah (http://www.jajah.com), qui propose de saisir sur 
une interface Web le numero de telephone de 1' appelant et celui de l'appele. Le service se 
charge de contacter tour a tour les telephones des deux correspondants en exploitant le 
reseau IP, en dehors de la boucle locale d'acces des correspondants, afin de beneficier 
d'un tarif attractif. 

Operateurs et equipementiers proposent plusieurs equipements telephoniques qui 
repoussent la contrainte de devoir allumer son ordinateur pour telephoner et simplifient la 
convivialite des appels dans un reseau IP devenu presque transparent. En particulier, il 
existe des telephones IP directement raccordables sur une prise Ethernet, sans necessiter 
l'utilisation d'un ordinateur. De meme, les boitiers, ou box, fournis par les fournisseurs 
d'acces Internet disposent d'un branchement pour un telephone non-IP, dont les flux sont 
automatiquement convertis par le boitier pour passer dans le reseau IP. 

Le service n'est toutefois pas toujours garanti, puisque la maitrise du reseau ne peut 
passer que par l'operateur, et non pas par l'editeur de logiciels. En outre, les appels 
d'urgence ne sont possibles que si l'utilisateur dispose d'un credit non nul. La qualite 
audio s'avere en revanche globalement bonne, parfois meilleure qu'en telephonie circuit 
classique. II est probable que les tarifs extremement competitifs des softphones vont 
modifier les comportements des utilisateurs, les incitant a passer plus de temps au tele- 
phone. 

Les chapitres suivants de l'ouvrage detailleront les logiciels de telephonie grand public 
les plus repandus que proposent les poids lourds de l'industrie, comme Skype, Microsoft, 
Yahoo! ou Google. 

Au terme de ce panorama necessairement simplificateur, une question se pose, a laquelle 
nous n'avons pu ou voulu repondre : parmi tous ces clients, lequel faut-il privilegier ? Le 
probleme est trop complexe pour pouvoir y apporter une reponse definitive. Tout depend 
des besoins et preferences. 

II convient de noter quelques caracteristiques fondamentales de ces logiciels, qui permet- 
tront selon les usages de choisir au cas par cas. Dans notre cadre, le logiciel doit impera- 
tivement posseder les fonctionnalites de telephonie sur IP. C'est le cas de toutes les solu- 
tions que nous allons presenter, qui proposent cette possibilite, avec une qualite audio 
globalement excellente. Les prix etant variables selon les destinations, et plus interessan- 
tes au cas par cas avec certains softphones qu'avec d'autres, le critere tarifaire s'avere 
difficilement distinctif a priori. 

Restent les services complementaires disponibles. L'ergonomie des logiciels est souvent 
affaire de gout, les uns preferant la simplicite d'une interface de type Google Talk, les 
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autres s'attachant davantage a la large palette de services et de personnalisation d'une 
interface de type Yahoo! Messenger. La compatibility et l'evolutivite des logiciels sont 
d' autres parametres a prendre en compte. Enfln, les services proposes varient selon les 
logiciels. En proposant un numero d'appel entrant associe a une messagerie, le logiciel 
Skype possede indeniablement une longueur d'avance sur ces concurrents au niveau de la 
telephonic 



9 



Skype 



Avec plus de 100 millions d'utilisateurs (dont 4 millions de Fran^ais) dans pres de 
225 pays, Skype, leader mondial et pionnier des offres de telephonie grand public sur 
Internet, bouleverse l'industrie des telecommunications en modiflant en profondeur les 
habitudes des consommateurs. 

Chaque jour, 150 000 nouveaux utilisateurs telechargent cette solution de peer-to-peer 
(P2P) qui propose deux services differents : une offre gratuite entre utilisateurs equipes 
du logiciel pour une exploitation purement Internet et une offre payante, qui permet de 
joindre et d'etre joint via Internet tandis que les correspondants utilisent la telephonie 
traditionnelle RTC. 

Skype est Tun des premiers logiciels grand public a avoir permis la jonction entre la tele- 
phonie du monde Internet et celle du monde RTC. C'est sans doute la la cle de son 
succes. Grace a une qualite d'ecoute excellente, une facilite d'utilisation ne necessitant 
generalement aucune configuration (y compris dans les infrastructures reseau deployant 
des pare-feu), une mobilite accrue, une gamme de services complementaires et un prix 
incomparablement moins cher que la telephonie traditionnelle, Skype s'est repandu de 
maniere virale. 

Skype a ete lance le 29 aout 2003 a 1'initiative de Niklas Zennstrom, un Suedois de 
36 ans, et Janus Friis, un Danois de 26 ans, tous deux experts en technologies de peer-to- 
peer puisqu'ils avaient fait fremir l'industrie de 1' entertainment au debut des annees 2000 
avec le logiciel Kazaa, qu'ils avaient con^u. 

Zennstrom et Friis ont ensuite lance Altnet, l'un des premiers services legaux de vente 
securisee de contenus commerciaux, egalement fonde sur le peer-to-peer. Encourages par 
ces experiences reussies, plusieurs partenaires ont soutenu le projet Skype en y investissant 
pres de 20 millions d'euros. 
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La societe Skype a vu le jour au Luxembourg et s'est tout de suite imposee sur le marche 
naissant de la telephonie logicielle. Grace a Skype, les internautes pouvaient communi- 
quer sur Internet par la voix, sans consideration de distance, ni de duree. Skype n'est pas 
le seul a proposer un service de ce type, mais la qualite de son service demeure inegalee, 
tant par le soin apporte a l'ergonomie de l'interface que par la simplicite de configuration 
du logiciel ou la qualite de la communication. 

Microsoft et Google d'abord, puis Yahoo! et News Corporation (la societe de Rupert 
Murdoch), s'interessent a Skype, mais, en 2005, ses deux fondateurs creent la surprise en 
vendant la societe a eBay, un acteur pour le moins inattendu dans le domaine des tele- 
coms. 

Le geant americain de la vente aux encheres sur Internet s'offre la jeune societe de TolP 
logicielle pour une somme record, comprise entre 2,1 et 3,3 milliards, qui laissera plus 
d'un analyste financier perplexe. Quelles motivations ont-elles pu pousser une entreprise 
prospere a se risquer dans un domaine qu'elle ne maitrise pas, qui n'est pas son secteur 
d'activite et qui la place en concurrent direct de mastodontes tels que Microsoft, Google 
ou Yahoo! ? 

L'objectif afflche par les dirigeants d'eBay etait de creer une synergie de son activite 
grace a la communication. Puisque le contact physique avec les objets mis en vente etait 
impossible, la possibilite de discuter de vive voix des caracteristiques des produits, de 
leur etat general ou des conditions de vente, voire de negocier pouvait devenir un veritable 
atout. 

En facilitant Facte d'achat, eBay s'ouvrait de nouveaux vecteurs de vente. De surcroit, 
fort de ses millions d'utilisateurs, Skype etait susceptible d'apporter une clientele impor- 
tante a sa nouvelle maison mere. En retour, Skype beneflciait du gigantesque reseau 
de clients pay ants d'eBay. Pour que la boucle soit bouclee, ce dernier a aussi rachete 
la societe PayPal, dont le site de vente aux encheres utilisait le systeme de paiement 
securise. 



Architecture de Skype 

Comme explique precedemment, Skype fonctionne selon un mode decentralise et une 
architecture peer-to-peer (P2P), c'est-a-dire de poste a poste, ou point-a-point, ou encore 
de pair en pair ou d'egal a egal, dans lequel chaque poste intermediate est susceptible de 
jouer le role de relais et de participer de maniere dynamique au processus d'acheminement 
des paquets. 

Le client logiciel n'est pas seulement utilise par le possesseur du logiciel. II est mis a 
contribution pour les besoins d'autres utilisateurs et sert de support de transmission aux 
flux de ces derniers. Chaque element du reseau (on parle de noeuds) constitue a la fois un 
client, qui peut demander un service, et un serveur, qui peut agir pour le compte d'un 
autre client. Ce modele distribue ainsi totalement ses traitements, a 1' oppose du tradition- 
nel modele client-serveur, dans lequel chaque entite joue exclusivement le role de serveur 
ou de client, ce qui necessite de centraliser les flux vers des centres de controle. 
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Le terme peer-to-peer est parfois utilise pour designer toute communication directe entre 
un poste et un autre, independamment du mode de routage des donnees utilise. C'est la 
un abus de langage, puisque le routage caracterise la technologie P2P et deflnit un moyen 
de transporter des informations faisant intervenir des terminaux intermediaries de proche 
en proche jusqu'au veritable destinataire. Skype est d'ailleurs le seul softphone parmi 
ceux que nous presentons dans les chapitres suivants a pouvoir utiliser un mode de 
routage de type peer-to-peer. 

Prenons un exemple concret. Si l'utilisateur Albert souhaite communiquer avec Beatrice, 
pour quelle raison ses communications doivent-elles etre acheminees vers le poste de 
Claude ? Le terminal de Claude n'a a priori rien d'un routeur. De plus, ses ressources 
privees vont etre mises a contribution sans qu'il en ait conscience. Le chemin le plus 
court etant evidemment le lien direct Albert-Beatrice, pourquoi passer par Claude et 
etablir le chemin Albert-Claude-Beatrice ? II y a deux raisons principales a cela, la volonte 
de limiter les ressources utilisees et celle de traverser les pare-feu. 

Limiter les ressources 

Le modele decentralise peer-to-peer propose par Skype fait reposer l'intelligence du 
reseau sur les utilisateurs eux-memes, et non sur des serveurs centraux. Des lors, le 
passage a l'echelle est permis a moindres frais, puisque chaque nouvel utilisateur est 
potentiellement une source de traitement pour 1' ensemble du reseau. 

Skype a ainsi pu s'etendre sur toute la planete sans avoir a s'interesser directement aux 
ressources de traitement de la montee en charge. C'est l'un des secrets de sa reussite. 

Traverser les pare-feu 

Une condition essentielle de la reussite de la ToIP est la possibilite de traverser les pare- 
feu. Les communications de ce type exploitent des ports dynamiques, qui ne sont 
generalement pas ouverts par ces pare-feu. Par ailleurs, le reseau sur lequel se trouve 
l'utilisateur peut mettre en ceuvre un mecanisme de NAT (Network Address Translation), 
ou translation d'adresse reseau, qui donne a l'utilisateur une adresse IP non routable sur 
Internet. Pour ces deux raisons, la communication directe entre correspondants est 
impossible. 

Skype a trouve la parade en exploitant differentes techniques. L'une d'elles consiste en 
l'utilisation de ports standards, qui sont etrangers a la telephonie sur IP, mais qui presen- 
ted l'avantage d'etre le plus souvent ouverts par les pare-feu. C'est le cas du port 80, 
associe generalement au Web pour le protocole HTTP. 

Skype permet en outre d' utiliser des ressources situees a l'exterieur de la zone protegee 
par le pare-feu. Cette ressource peut etre un utilisateur parmi d'autres, choisi pour 
accomplir cette tache selon un algorithme proprietaire. Les flux IP de Skype suivent ainsi 
un chemin detourne lorsque le chemin direct est impossible. Ce sont de tels chemins 
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qu'empruntent les communications entre utilisateurs de Skype, lesquels se pretent a la 
fonctionnalite de routage sans en avoir conscience et pour les besoins d'autres clients. 

Ce type de connexion s'effectue aux depens des utilisateurs intermediaries, mais a un 
debit tres faible, de 0,5 Ko/s, qui ne perturbe que tres peu ces derniers. Ceux-ci sont en 
outre selectionnes en fonction de la bande passante dont ils disposent afln d'assumer la 
charge supplemental induite par ces communications. L'idee du transfert relay e est 
d' avoir une communication, fut-elle de qualite mediocre, plutot que pas de communication 
du tout. 

Si 1' architecture de Skype est globalement decentralisee, il existe cependant des 
serveurs centralises, qui assurent un ensemble de fonctionnalites annexes indispensa- 
bles a la communication. Par exemple, pour savoir si un utilisateur est connecte ou non, 
le logiciel se connecte a l'un de ces serveurs, qui informe de la disponibilite de tous les 
contacts. 



Les offres Skype 

Pour l'appel entre internautes, le service Skype est totalement gratuit, ainsi que la visio- 
phonie, la messagerie instantanee, la videoconference et le transfert de fichiers. Cette 
formule ne permet de communiquer qu' entre internautes, ce qui represente une restriction 
importante. 

Outre cette offre d'appel, plusieurs services payants sont proposes, tels que les possibili- 
tes de communiquer avec les utilisateurs du reseau telephonique commute ou de disposer 
d'un numero d'appel entrant et d'une messagerie vocale associee. 

Deux options pay antes sont proposees,: 

• SkypeOut permet d'appeler a partir du logiciel et done d' Internet vers le reseau tele- 
phonique traditionnel (fixe ou mobile). Cette option est le fruit de partenariats mis en 
place au niveau mondial avec des operateurs de telephonie tels que Colt, Level 3 
Communications, iBasis et Teleglobe, assurant une tres large couverture de la zone 
Europe, Etats-Unis et Asie. 

• Skypeln permet d'etre appele a partir de telephones fixes ou mobiles. L' utilisateur de 
Skype dispose pour cela d'un numero de telephone, qui se presente sous la forme d'un 
numero geographique standard. Lorsqu'un appelant souhaite joindre un abonne ayant 
souscrit au service Skypeln, il compose simplement son numero d'appel. Cette 
communication est facturee par l'operateur de l'appelant au prix d'une communication 
dependante du numero geographique de 1' appele. Autrement dit, si 1' appele possede un 
numero geographiquement lie a la region de l'appelant, ce dernier sera facture au prix 
d'une communication locale, quel que soit le lieu ou se trouve physiquement 1' appele. 
Ce service est couple avec une messagerie vocale. Les messages vocaux enregistres 
peuvent ensuite etre envoyes par e-mail en fichier audio a 1' abonne appele. 
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Partenariats technologiques et commerciaux 

Skype s'ouvre progressivement a des editeurs et integrateurs tiers. L'une des premieres 
etapes dans cette direction a ete la publication d'une API diffusee sous le nom de Skype- 
Net permettant l'integration du logiciel directement depuis un site Internet. Auparavant, 
seule une fenetre applicative du logiciel permettait aux utilisateurs de telephoner entre 
eux. Depuis la publication de cette API, tout concepteur et developpeur de pages Web 
peut exploiter les fonctionnalites de Skype sur une page Web. Sans etre une nouveaute 
technologique, cet outil constitue une forme d'ouverture du logiciel, auparavant protege 
et ferme, qui lui permet de renforcer sa presence sur Internet. 

Les partenariats se sont ensuite etendus a de grands constructeurs de materiels de tele- 
phonie, tels Siemens, Panasonic, Creative, Linksys ou US Robotics, avec lequel Skype a 
congu des combines telephoniques utilisant son logiciel pour permettre d'appeler aussi 
bien sur Internet que sur le reseau telephonique classique. 

Ces telephones utilisent une connexion filaire ou sans fil, de type DECT ou encore 
Wi-Fi, et ressemblent en tout point a des telephones traditionnels, le logiciel Skype et 
la connectivity IP en prime (voir figure 9.1). Pour garantir le bon fonctionnement des 
appareils, qu'il s'agisse de la gamme de combines telephoniques ou des accessoires 
tels que les microcasques, la firme s'est meme dotee d'un label commercial, appele 
Skype Ready, qui fait office de norme d'interoperabilite afin de rassurer les consom- 
mateurs. 







/ 




Figure 9.1 

Telephones Skype 
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La securite 



Si aucune attaque ou vulnerability critique concernant le logiciel n'a encore ete recensee, 
de nombreux specialistes deplorent la facilite avec laquelle le logiciel parvient a traverser 
et se jouer des pare-feu censes bloquer les flux non autorises. De ce fait, ces experts 
recommandent d'interdire l'utilisation du logiciel dans un cadre professionnel. 

De leur cote, les autorites s'inquietent du manque de transparence du logiciel, qui se 
comporte comme une boite noire. II n'est done pas possible de savoir s'il contient une 
porte derobee, accessible a partir d'Internet, pas plus qu'il n'est possible de savoir si des 
donnees sensibles sur les utilisateurs ne sont pas envoyees a leur insu. 

Quant au fondement meme du logiciel, le peer-to-peer, puisque les communications 
peuvent etre acheminees via des ordinateurs intermediates, elles peuvent faire l'objet 
d'ecoutes clandestines par ces memes intermediaries. 

De meme, les pieces jointes transmises par l'outil de transfert de fichiers de Skype ne 
sont pas soumises a des controles d' antivirus. Meme si Ton peut supposer que les inter- 
locuteurs sont dignes de confiance, il n'en va pas forcement de meme des fichiers qu'ils 
transferent, qui peuvent avoir ete corrompus. 

Selon un raisonnement paranoi'aque, on pourrait imaginer que toutes les communications 
soient relayees vers des serveurs centraux qui les enregistreraient, agissant comme un 
systeme automatise de profiling des utilisateurs. Techniquement, ce serait parfaitement 
realisable. Dans le doute, et dans la mesure ou Skype refuse d'ouvrir les specifications de 
son protocole, on comprend la mefiance de certains. 

Chez Skype, on garantit que le logiciel est parfaitement securise et ne presente aucun 
risque pour l'internaute. Le cryptage se fait de bout en bout, au moyen de 1'algorithme de 
chiffrement symetrique AES (Advanced Encryption Standard), le standard utilise par les 
organisations gouvernementales aux Etats-Unis. AES utilise un cryptage sur 256 bits. La 
negotiation des cles symetriques AES s'effectue par 1'algorithme RSA (Rivest Shamir 
Adleman), avec des cles de 1 536 a 2 048 bits. 

Si les specifications generates du protocole ne sont pas rendues publiques, explique-t-on 
chez Skype, e'est uniquement pour offrir au logiciel une protection supplemental et 
eviter de donner aux pirates l'occasion d'y chercher des failles. 

En entreprise, meme si des administrateurs souhaitent bloquer l'utilisation de Skype chez 
les utilisateurs de leur reseau, dans la pratique il est tres difficile de mettre en place une 
politique de securite qui prenne en compte les specificites du logiciel. Le cryptage 
rendant impossible le filtrage, il n'est meme pas possible de proteger le logiciel d'atta- 
ques malicieuses ou de le rendre compatible avec un systeme de detection d' intrusion 
IDS (Intrusion Detection System) puisque les echanges ne sont pas analysables. 

Plusieurs societes proposent des logiciels qui detectent et bloquent les flux de Skype. 
Appeles SkypeKiller, ces logiciels poussent la reconnaissance de 1' analyse protocolaire 
jusqu'au niveau applicatif ou comportemental, et pas uniquement en se fondant sur les 
protocoles de transport ou les ports, afin d'empecher les flux Skype de traverser le reseau. 
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Utiliser Skype 



Skype est aujourd'hui le logiciel de ToIP le plus utilise au monde. Meme si l'arrivee dans 
ce secteur d'acteurs aussi importants que Google, Yahoo! et Microsoft promet des evolutions 
majeures, Skype demeure une reference pleinement fonctionnelle. 

Nous allons detailler la richesse du logiciel, a travers ses fonctionnalites les plus couran- 
tes. Quoique simple d' utilisation, nous verrons qu'il offre une gamme de possibilites tres 
etendue. 



Prerequis 



Skype est disponible gratuitement en telechargement. II est disponible pour les quatre 
plates-formes suivantes : 

• Windows 2000 , XP et Vista; 

• MacOSX; 

• Linux, avec notamment des installeurs deja disponibles pour les distributions Suse, 
Mandriva et Fedora, ainsi qu'une version binaire pouvant etre installee sur d'autres 
types de distributions Linux ; 

• Pocket PC, sous Windows Mobile 2003, Windows Mobile 5.0, Windows Mobile 6.0, 
permettant une utilisation nomade, pour une connexion en Bluetooth, Wi-Fi ou 3 G, 
par exemple. 

Pour communiquer, un microcasque est necessaire, ainsi qu'une webcam si Ton souhaite 
proflter des appels avec video. 

La machine sur laquelle on souhaite installer le logiciel doit avoir au minimum un 
processeur cadence a 400 MHz, 15 Mo de disponible sur disque dur, ainsi qu'une 
memoire vive de 128 Mo. Si Ton se limite a une connexion audio, une connexion Inter- 
net par modem a 56 Kbit/s est suffisante. Dans ce cas, il importe de ne pas avoir de tele- 
chargements en parallele, qui pourraient perturber le service de telephonic 

Pour une connexion video, il faut disposer d'une connexion haut debit. En moyenne, 
pour l'audio uniquement, la bande passante doit etre comprise entre 3 et 16 Ko/s. Le 
codec utilise pour une communication est automatiquement selectionne d'apres la bande 
passante disponible chez l'interlocuteur et les conditions intermediates du reseau. En 
1' absence d'appel, Skype utilise une bande passante inferieure a 500 o/s, essentiellement 
pour mettre a jour les informations de presence et de statut sur les contacts. La bande 
passante peut aussi etre utilisee en petite quantite pour d'autres utilisateurs si un utilisateur 
sert de relais a d'autres communications. 

Dans ce qui suit, nous nous interessons uniquement a la version Windows de Skype, qui 
est la plus utilisee. Les autres versions ont une interface differente, mais on y retrouve des 
fonctionnalites semblables. 
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Appeler 



Apres avoir telecharge et installe le logiciel Skype, il est necessaire de creer un compte 
Skype qui permettra de se connecter au reseau Skype. 

Des lors, les premiers appels avec le logiciel sont possibles. Pour tester le bon fonction- 
nement du logiciel, un contact special, nomme « echo 123 », qui se trouve dans l'onglet 
des contacts du logiciel, est automatiquement ajoute lors de 1' installation du logiciel. 
II suffit de cliquer sur ce contact pour initier un appel de test. La fenetre illustree a la 
figure 9.2 s'affiche alors, avec notamment l'indication de la duree de 1' appel. Un 
message vocal invite 1' appelant a enregistrer un message audio de 10 secondes qui lui est 
immediatement retransmis. 

Si la langue choisie lors de 1' installation est le fran^ais, le message audio est diffuse en 
fran^ais. La connectivite est assuree si 1' appel est correctement realise. La reception du 
son est validee si 1' appelant entend le message d'accueil de maniere satisfaisante. De 
meme, remission est validee si le message que Ton a transmis est correctement rendu. 



Figure 9.2 

Appel de test 
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Pour connaitre la disponibilite d'un contact avant meme de l'appeler, il faut l'ajouter a sa 
liste de contacts. Pour cela, on peut indifferemment utiliser le bouton Ajouter un contact 
ou selectionner Ajouter un contact dans le menu Contacts. 

Comme illustre a la figure 9.3, des la premiere tentative de communication, l'appelant 
re^oit ce message personnalise, lui indiquant qu'un utilisateur tente de l'ajouter a sa liste 
de contacts et 1' invite a en faire autant. L'appelant peut soit accepter la demande, soit la 
refuser. Les communications vocales sont possibles entre les deux intervenants dans le 
premier cas, et bloquees dans le second. 
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Figure 9.3 

Accepter ou refuser un contact 

En acceptant ce contact, son identifiant est automatiquement ajoute a la liste des contacts. 
Dorenavant, sa presence et sa disponibilite sont immediatement visibles, et il n'est plus 
necessaire pour initier une communication avec lui de specifier son pseudonyme, son 
nom ou son numero de telephone. 

D'autres informations sont afflchees par defaut dans la zone relative au contact, comme 
l'image qu'il s'est choisie, son pays ou son heure locale (voir figure 9.4). 



Figure 9.4 

Nouveau contact de la liste 
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En double-cliquant sur un contact, la communication audio est initiee. L'appele est 
immediatement informe par une sonnerie ainsi qu'une alerte visuelle (voir figure 9.5) 
qu'un correspondant cherche a le joindre. L' alerte lui precise les nom et prenom de 
1' appelant, en lui laissant choisir d' accepter ou non l'appel. 



Figure 9.5 

Reception d'un appel 
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L' absence prolongee de reponse est naturellement consideree comme une absence du corres- 
pondant. Si l'appele choisit de rejeter l'appel, 1' appelant est informe que la communi- 
cation n'a pas ete acceptee. Si l'appele accepte l'appel, la communication debute 
instantanement. 
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Outils 



Parce qu'il se veut a la fois convivial et complet, Skype fourni une gamme d' outils 
facilitant son utilisation au quotidien. Ces outils sont progressivement devenus des clas- 
siques, que Ton retrouve sous differentes formes dans les autres logiciels grand public de 
telephonie et de messagerie instantanee. 

Indicateur de presence 

Skype dispose d'un indicateur de presence symbolisant la disponibilite de chacun des 
contacts de la liste. 

Chaque utilisateur peut afflcher son statut, c'est-a-dire son activite actuelle, selon les 
possibilites suivantes : Deconnecte, Connecte, Absent, Indisponible, Ne pas deranger, 
Skypez-moi, Invisible. 

Ces indicateurs peuvent etre dermis de plusieurs manieres (voir figure 9.6) : 

• en selectionnant Statut de connexion dans le menu Fichier ; 

• en cliquant sur le logo a gauche de son nom, sous barre d' outils ; 

• en cliquant sur le logo en bas a gauche de 1' interface du logiciel (partie droite de la 
figure) ; 

• en cliquant sur l'icone de la zone d'etat systeme puis en selectionnant « changer de 
statut ». 



Figure 9.6 

Configuration du statut 
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Le statut Skypez-moi permet a tout internaute, meme s'il ne figure pas dans la liste de 
contacts, d'indiquer sa disponibilite. Le statut Invisible permet de voir la liste des person- 
nes connectees sans etre soi-meme visible de ces contacts. 

L'inactivite prolongee d'un poste, sans mouvement de la souris ni utilisation du clavier, 
peut amener le logiciel a se positionner automatiquement sur le statut Absent. 
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Salons de discussions 



Un nouveau service, nomme Skypcast, permet de creer ses propres salons de discussions 
ou de rejoindre des salons existants. Ce service gratuit permet de gerer jusqu'a 100 parti- 
cipants et est bien adapte aux conferences, meme professionnelles. 

L'initiateur du salon en est le moderateur. II est done habilite a autoriser ou bloquer les 
intervenants a parler. Deux modes de gestion de la conference sont proposes : 

• Mode libre, dans lequel chacun peut communiquer quand il le souhaite et intervenir 
sans demander l'acces. Le moderateur se contente de s'assurer que les echanges ne 
derivent pas des regies generates d' utilisation du service Skypcast. 

• Mode regule, dans lequel les intervenants doivent se faire connaitre aupres du modera- 
teur pour avoir la possibilite de prendre la parole tour a tour. En plus de son role de 
controle des regies, le moderateur a celui de donner la parole aux intervenants. 

Le moderateur peut decider dynamiquement de basculer dans un mode ou un autre. 

Transfert de fichiers 

II n'est pas surprenant de la part des concepteurs de Kazaa d' avoir inclus dans Skype la 
possibilite de transferer des fichiers en peer-to-peer. 

Plusieurs manieres permettent de realiser un transfert de fichiers : 

• En depla^ant les fichiers a envoy er sur l'icone du contact destinataire ou dans la fenetre 
de ce contact, si elle est ouverte. 

• En selectionnant un contact dans la liste puis en cliquant sur le bouton d' envoi de flchier. 

• En selectionnant un contact par clic droit puis en selectionnant 1' option d' envoi dans le 
menu contextuel qui s'afflche. 

Le transfert de fichiers est securise par un cryptage analogue a celui utilise pour les 
communications et autorise la reprise d'un telechargement interrompu. Si une deconnexion 
intervient alors que le flchier n'est pas totalement transfere, le transfert peut reprendre ou 
il a ete interrompu, et non depuis le debut. 

Notons que les documents envoyes par ce moyen ne sont soumis a aucun test d' antivirus, 
ni par un serveur intermediate (il n'y a pas de serveur centralise pour les transferts) ni 
par le logiciel lui-meme (ce dernier ne dispose pas d' antivirus). 

Aller plus loin avec Skype 

Certaines options evoluees de Skype permettent d'ameliorer la convivialite et l'utilisation du 
logiciel. 

II est ainsi possible d'ouvrir plusieurs instances de Skype, de travailler en ligne de 
commande, de creer des commandes textuelles ou d'integrer Skype dans ses pages Web 
et courriers electroniques. 
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Ouvrir plusieurs instances de Skype 

Si Ton souhaite partager son poste de travail avec des amis ou des membres de sa famille, 
il peut etre utile de lancer plusieurs instances du logiciel. Un meme utilisateur peut aussi 
avoir plusieurs comptes, par exemple en dissociant compte prive et professionnel. Skype 
empeche par defaut le lancement de deux instances du programme, mais il est possible de 
contourner cette contrainte. 

Deux courtes etapes sont necessaires pour cela. La premiere, effectuee une fois pour 
toutes, consiste a creer un second compte utilisateur sous Windows, et la seconde a lancer 
le programme sous le compte utilisateur que Ton vient de creer. 

Nous allons detailler ces deux operations. Nous supposons que nous disposons de deux 
comptes Skype, qu'une premiere instance de Skype est deja lancee sur le poste de travail 
avec le premier compte Skype et que nous souhaitons ouvrir une nouvelle instance avec 
le second compte. 

Pour la creation d'un nouveau compte utilisateur sous Windows, il faut se rendre dans la 
section Comptes d'utilisateurs du Panneau de configuration et selectionner Creer un 
nouveau compte. II sufflt alors d'entrer un nom associe a ce compte et de lui attribuer les 
droits d'administrateur. En cliquant sur l'icone creee pour ce compte, on peut attribuer un 
mot de passe au compte. 

Pour executer Skype sous le compte qui vient d'etre cree, il faut se rendre a 1' emplace- 
ment ou le programme a ete installe. Ce chemin a ete indique lors de 1' installation du 
logiciel Skype. Par defaut, le repertoire utilise se trouve dans C:\Program Files\Skype\ 
Phone. II sufflt d' ouvrir ce repertoire puis, par un clic droit sur l'icone de Skype, de choisir 
1' option « Executer en tant que. . . » dans le menu contextuel (voir figure 9. 7). 
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Figure 9.7 

Menu contextuel Windows 
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Une nouvelle fenetre propose de s' identifier sous un autre nom, comme illustre a la 
figure 9.8. II suffit de selectionner la case « L'utilisateur suivant », pour specifier le nom 
et le mot de passe associes au nouveau compte Windows. 



Figure 9.8 
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Apres avoir renseigne les informations fournies a l'etape de creation du compte 
Windows, Skype peut se lancer sous une nouvelle instance, et il devient possible de 
s' identifier sous un autre compte Skype a partir de cette instance. 

On obtient ainsi deux executions differentes du meme programme, comme 1' illustre la 
figure 9.9. 
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Les deux icones afflchees dans la zone d'etat systeme (voir figure 9.10) n'etant pas disso- 
ciables Tune de l'autre, il est recommande de ne pas les utiliser par clic droit mais de se 
contenter de les activer par double-clic pour faire apparaitre la fenetre principale permettant 
d'activer le compte desire. 



Figure 9.10 

Icones systeme des deux instances 
de Skype 




De cette maniere, on peut lancer autant d' instances du programme Skype que Ton 
souhaite et ainsi recevoir les appels destines a chacun des comptes associes. 

II est possible d'optimiser le lancement de la seconde etape en creant un raccourci vers 
Skype (par clic droit sur l'icone de Skype puis en selectionnant Creer un raccourci. Une 
fois le raccourci cree, il sufflt de le selectionner par clic droit et de cliquer sur Proprietes. 
Dans l'onglet Raccourci, il faut ensuite cliquer sur le bouton Avances puis sur la case 
« Executer en utilisant d'autres informations d' identification » avant de valider 
(voir figure 9.11). Desormais, chaque fois que Ton clique sur ce raccourci, on afflche la 
fenetre de saisie de 1'identiflant et du mot de passe du compte Windows avec lequel on 
souhaite executer le logiciel Skype. 



Figure 9.11 

Proprietes avancees 
de Skype 
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Une methode encore plus rapide consiste a utiliser des programmes tels que FireDaemon 
Windows Service (gratuit, mais en anglais). FireDaemon Windows Service a pour voca- 
tion d'automatiser la saisie des parametres d'authentiflcation Windows lors du lancement 
de programmes. 

Apres avoir telecharge, installe et execute 1' application, une interface invite a saisir le 
nom de l'application a lancer et les login/mot de passe associes. De cette maniere, il n'est 
meme plus necessaire de renseigner les informations d'authentiflcation Windows, et le 
lancement de la seconde instance de Skype est immediat. 

II existe cependant une limitation a l'utilisation de ces methodes, qui vient de ce 
qu'une seule carte son ne permet pas de converser simultanement sur plusieurs 
comptes Skype lances sur un meme PC. La solution a ce probleme consiste tout 
simplement a installer plusieurs cartes son et a associer a chaque compte un periphe- 
rique different. 

Comme illustre a la figure 9.12, la section Options du menu Outils de Skype propose un 
onglet Audio qui permet de realiser cette association. Si Ton dispose d'un terminal tele- 
phonique dedie a Skype, comme on en trouve dans le commerce, il est possible de le 
specifier dans cette section et de s'en servir comme peripherique complementaire a la 
carte son du PC. 
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Options en ligne de commande 

Skype peut etre execute par le biais d' options complementaires executables en ligne de 
commande. 

Les quatre options suivantes sont disponibles : 

• /nosplash. Par defaut, Skype afflche son logo avant le lancement du logiciel. Cette 
option interdit l'afflchage du logo et lance immediatement le logiciel. 

• /minimized. Par defaut, Skype ouvre sa fenetre principale en premier plan. Cette option 
permet de minimiser le logiciel directement dans la zone d'etat systeme lors de son 
lancement. 

• /callto: numero _ou_identifiant_a_appeler (en remplacement de la partie numero _ou_iden- 
tifiant_a_appeler par un identiflant Skype ou un numero de telephone). Cette option 
permet d'appeler automatiquement le numero ou l'identiflant Skype correspondant par 
simple clic sur l'icone de ce raccourci. Elle suppose bien sur que les credits soient sufflsants 
pour cet appel, s'il est pay ant. Dans le cas contraire, un message d'erreur est retourne. Cette 
option peut se reveler utile pour des contacts tres frequemment appeles. 

• /shutdown. Cette option ferme directement le programme Skype. 

Pour specifier ces options, il faut creer un raccourci vers Skype (par clic droit sur l'icone 
de Skype puis en selectionnant Creer un raccourci) puis selectionner ses proprietes par 
clic droit a nouveau et en choisissant Proprietes dans le menu contextuel. 

Dans l'onglet Raccourci, la case Cible permet de personnaliser le lancement avec les 
options desirees en ajoutant apres les guillemets les options qui seront activees lorsqu'on 
cliquera sur cette icone (voir figure 9.13). 



Figure 9.13 

Options de raccourci 
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Commandes textuelles 



Au cours d'une conversion par messagerie instantanee, il est possible d'utiliser un certain 
nombre de commandes textuelles dans la zone de saisie de texte. Toutes ces commandes 
doivent etre precedees d'un slash. 

En saisissant la commande /help, on obtient le recapitulatif des commandes disponibles, 
dont voici le detail : 

• /add identifiant_skype. Permet d'inviter un contact a se joindre a la conversation en 
cours (en rempla^ant identifiant_skype par l'identiflant du contact a inviter). Par 
exemple, /add Nathalie ajoute l'utilisateur Nathalie a la conversation en cours. 

• /topic sujet. Permet de specifier ou modifier le theme de la conversation. Dans une 
conversation avec de nombreux participants, il est ainsi possible d'indiquer clairement 
en haut de la fenetre le theme de la discussion. C'est une maniere d'orienter ou 
d'animer le dialogue. Par exemple, /topic BonAnniversaire Simon ! specifie en haut de 
l'ecran le sujet « Bon anniversaire Simon !». 

• /me message. Permet de mettre 1' accent sur une action par un message particulier qui 
sera mis en relief. Cette commande est suivie d'un message textuel. Par exemple, si 
Rebecca saisit la commande /me est au telephone avec Henri /, chaque utilisateur avec 
qui Rebecca est en conversation verra s'afficher dans sa fenetre le message « Rebecca 
est au telephone avec Henri ! » encadre et centre. 

• /history (sans argument). Affiche l'historique des messages. 

• /find texte _a_chercher. Recherche dans la communication en cours le texte indique. La 
premiere occurrence est selectionnee et surlignee. Les suivantes sont accessibles en 
appuyant sur la touche F3. 

• /fa ou I (sans argument). Repete la recherche precedemment effectuee. La commande a 
le meme effet que la touche F3. 

• /leave (sans argument). Permet de fermer la fenetre de la messagerie instantanee. 

• /alertson texte. Active une alerte qui sera declenchee en mettant en surbrillance le texte 
repere dans une conversation. C'est notamment utile si Ton ne souhaite pas suivre la 
totalite d'une conversation avec de multiples intervenants mais que Ton desire etre 
alerte par des elements susceptibles de nous interesser. Ces alertes peuvent etre annulees 
en saisissant simplement la commande sans argument textuel. 

• /alertsoff (sans argument). Desactive les alertes d'avertissement de messages, ce qui 
evite que la fenetre de messagerie instantanee clignote dans la barre des taches a 
chaque nouveau message. 

• /call identifiant_skype. Permet d'appeler au telephone (en rempla^ant 
identifiant_skype par l'identiflant du contact a inviter). Par exemple, /call Marc lance 
un appel telephonique a l'utilisateur Marc. 
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Integrer Skype dans ses pages Web et ses e-mails 

Si un utilisateur maintient un site Web, il peut inserer dans ses pages des liens invitant les 
internautes a le contacter par Skype pour obtenir des informations complementaires ou 
simplement converser. 

II sufflt pour cela d' inserer des balises specifiques dans ses pages Web. Ces balises s'inserent 
comme un code HTML dans un lien hypertexte. 

La syntaxe generale d'une balise Skype respecte la forme suivante : 



<a href= 


= "skype: 


contc 


ict(s) 


Taction 


■> 


Message 


textuel 










</a> 













Cette balise comporte trois parties a remplacer selon les usages : 

• contact(s). Specifie le contact Skype concerne par le lien hypertexte. Le contact peut 
etre indique par un identiflant Skype ou par un numero de telephone standard. II peut 
etre unique ou concerner plusieurs contacts separes par des points- virgules. 

• action. Specifie Taction a enclencher lors d'un clic sur le message textuel. Les actions 
les plus classiques sont les suivantes : 

- call : appelle le ou les contacts mentionnes ; c'est Taction par defaut. 

- add : ajoute le ou les contacts mentionnes a sa liste de contacts. 

- userinfo : affiche le profil du ou des contacts mentionnes. 

- chat : lance une conversation par messagerie instantanee avec le ou les contacts 
mentionnes. 

- sendfile : envoie un fichier aux contacts mentionnes. 

• Message jtextuel C'est le message textuel affiche sur la page Web a Tinternaute. 

Par exemple, pour lancer une conference audio avec les utilisateurs guy.laurent et 
dupont.durand en cliquant sur un lien hypertexte de sa page Web, il sufflt de placer la 
balise suivante dans le code source de la page, a V emplacement ou Ton souhaite afficher 
un message textuel invitant Tutilisateur a cette conference : 

|<a href="skype:guy.laurent;dupont.durand?cal 1 "> 
Telephoner a Guy Laurent et Dupont Durand 
</a> 

En cliquant sur ce lien, le navigateur de Tinternaute instancie automatiquement Tapplica- 
tion Skype et initie Tappel vers ces correspondants. Bien evidemment, cela suppose que 
Tapplication Skype soit installee sur le poste de Tinternaute. Dans le cas contraire, le 
navigateur de Tinternaute ne parvient pas a interpreter ce code Skype et lui indique une 
erreur. 
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De la meme maniere, les coordonnees Skype peuvent etre indiquees en signature d'un e-mail, 
pour permettre au correspondant de lancer un appel d'un simple clic sur 1' e-mail. 

Utiliser une image de statut 

Ces balises permettent aux internautes de contacter les auteurs des pages Web ou des 
courriers electroniques qui les comportent, mais pas d'etre informes de la disponibilite 
de ces derniers. Pour faciliter la mise en relation, Skype propose des scripts qui testent la 
presence des utilisateurs et l'affichent sous la forme d'une image dynamique. Ce service 
est appele SkypeWeb. 

L' image permet non seulement de specifier les coordonnees (identiflant ou numero de 
telephone) d'un contact Skype, mais aussi de detecter et d'afflcher son statut de disponi- 
bilite. Ainsi, les internautes peuvent savoir avant d'appeler si leur correspondant est en 
ligne. 

Un exemple d'image de statut Skype est illustre a la figure 9.14. II est possible de person- 
naliser cette image. 



Figure 9.14 

Image de statut Skype 



'm online 



Pour afflcher son statut, il faut tout d'abord avoir autorise la diffusion de cette informa- 
tion dans le logiciel Skype lui-meme. Pour cela, il faut selectionner Options dans le menu 
Outils, puis, dans la fenetre des options qui s'ouvre, cocher la case « Permettre que mon 
statut soit visible depuis le web » de la section Filtres & Vie privee. 

II ne reste qu'a ajouter dans sa page Web ou comme signature de ses e-mails l'icone 
afflchant ce statut. 

Nous allons utiliser une icone disponible sur le site de Skype, mais il est possible d'en 
choisir une autre (a l'adresse http://www.skype.com/go/skypebuttons) ou d'en generer une soi- 
meme. 

Dans le corps du code de la page Web (apres la balise <body> et a 1' emplacement ou Ton 
desire ajouter l'icone Skype), il sufflt d'inserer la section de code suivante (ce code affl- 
che une icone recuperee sur le site de Skype et lui donne l'apparence correspondant a son 
propre statut) : 



<script type=" text/ javascript" 
^js/skypeCheck. js"> 
</script> 



src="http:/ /down load. sky pe.com/share/skypebuttons/ 



<a href="skype:guy%2Elaurent?call"> 

<img src="http://mys tatus.skype.com/bi gel assic/guy%2Elaurent" 

*" width="182" height="44" alt="Mon statut Skype" /> 

</a> 



style="border: none; 
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Dans les trois premieres lignes, on charge une page de script en langage JavaScript dispo- 
nible sur le site de Skype arm de verifier les statuts des utilisateurs. Comme l'indique la 
balise suivante <a href>, un clic sur l'image dont le code suit appelle l'utilisateur 
guy.laurent (le code %2E correspond au point). L'image est renseignee ensuite. Son 
emplacement se trouve directement sur le site de Skype, a l'adresse http://mysta- 
tus.skype.com/bigclassic. II n'est done pas necessaire de la fournir dans sa page Web. 

En rempla^ant le mot bigclassic dans l'adresse precedente par balloon, srnallclassic, 
smallicon ou mediumicon, on obtient d'autres images utilisables de la meme maniere. 
Toutes ces images utilisent un parametre qui est l'identiflant de l'utilisateur Skype et qui 
doit etre fourni a sa suite. En utilisant le script insere juste au-dessus, ce parametre 
permet d'afflcher l'image selon le statut reel de l'utilisateur dont l'identiflant est fourni. 
Periodiquement, le statut de l'utilisateur est teste, et l'image correspondante actualisee au 
besoin. 

Independamment des balises, mentionnons 1' existence d'un module additionnel pour les 
navigateurs Internet Explorer et Mozilla Firefox. Ce module se presente sous la forme 
d'une barre d'outils appelee Skype Web Toolbar, qui s'integre au navigateur une fois son 
installation effectuee. Des lors, tous les numeros de telephone et identiflants Skype diffu- 
ses sur le Web sont automatiquement reconnus et exploitables par le logiciel en un simple 
clic. 

Recommandations et resolution de problemes 

II est vivement recommande d'utiliser un microcasque de bonne qualite, faute de quoi la 
communication s'en res sent. 

Dans la majorite des cas, les problemes rencontres se resolvent facilement en veriflant un 
certain nombre de points elementaires. 

Voici quelques recommandations simples en cas de problemes rencontres dans 1' utilisation 
de Skype : 

• Verifier sa connexion Internet en ouvrant une page Web avec son navigateur. 

• Eviter d'effectuer des transferts en parallele d'une communication, surtout si le debit 
est limite. Skype necessite un debit minimal pour fonctionner, et il revient a l'utilisa- 
teur de veiller a en disposer. Dans la pratique, un debit insufflsant peut provoquer des 
hachures lors de la communication ou des interruptions desagreables. Elles peuvent 
provenir du poste de travail de 1' appelant comme de celui de l'appele. 

• Un simple redemarrage resout bien des problemes mysterieux. 

• Tester une communication en se connectant sur son compte a partir d'un autre poste 
de travail. Cela permet de savoir si le probleme provient du compte Skype ou du poste de 
travail utilise. Si la communication demeure possible sur un autre poste de travail, le 
probleme peut etre localise sur le premier poste. Si Ton ne dispose pas d'un autre 
poste de travail, on peut toujours utiliser le meme poste, mais avec un compte Skype 
different. 



Skype 



Chapitre 9 

• S' assurer que d'autres utilisateurs arrivent a communiquer. Si le probleme est situe au 
niveau des serveurs de Skype, il faut attendre le retablissement du service. 

• Verifier (en le saisissant a nouveau) que le mot de passe du compte est correct et n'a 
pas ete modifie. 

• Tester une communication avec le contact test « echo 123 ». Cela indique de maniere 
flable si le microcasque fonctionne correctement. Au besoin, mettre a jour le pilote de 
sa carte son. 

• Utiliser les guides, FAQ et aides en ligne de Skype. Un grand nombre de ces documents 
sont disponibles en fran^ais. 

Si ces conseils de base ne sufflsent pas a la resolution de problemes plus complexes, les 
forums specialises sur Skype sont generalement assez reactifs. 



Conclusion 



En proposant une solution de ToIP logicielle simple, flable et bon marche, Skype s'est 
fait un nom et a perturbe un equilibre que Ton croyait etabli. Skype grandit chaque jour 
au point de devenir incontournable dans le grand public et de s' installer progressivement 
dans les entreprises. 

Les forfaits de telephonie illimitee proposes dernierement par de nombreux operateurs 
remettent cependant en cause le modele meme de Skype. Reste qu'avec Skype, l'utilisa- 
teur peut etre mobile et disposer d'un indicateur de presence, de la video en plus du texte, 
des echanges de flchiers et des conferences a plusieurs. 

A sa defaveur, Skype ne repose sur aucun protocole normalise et n'est pas ouvert aux 
protocoles concurrents. Si Skype ne s'ouvre pas a la compatibilite, il risque de s'enliser 
au moment meme ou ses concurrents se rassemblent, a 1' image du rapprochement des 
systemes de messagerie de Microsoft et de Yahoo!. 

De plus, en utilisant un protocole proprietaire, incompatible aussi bien avec H.323 que 
SIP, Skype empeche ses utilisateurs de migrer facilement vers des solutions concurrentes. 
C'est la un frein majeur a son developpement. 
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Windows Live Messenger 
et Yahoo! Messenger 



Acteurs majeurs du monde de l'lnternet, Microsoft et Yahoo! proposent une vaste gamme 
de services similaires : moteur de recherche, messagerie Web, mais aussi messagerie 
instantanee. 

Utilisee par plusieurs millions de personnes dans le monde, la messagerie instantanee n'a 
pas echappe a la deferlante de la ToIP et permet desormais a ses utilisateurs de telephoner 
vers le reseau RTC traditionnel, en plus des conversations audio et video sur le reseau IP. 

Ce chapitre presente les principales caracteristiques de ces deux logiciels et montre 
comment les mettre en oeuvre, a la fois pour la telephonie mais aussi pour les autres fonc- 
tionnalites remarquables dans cette convergence des services. 

Windows Live Messenger 

Microsoft aborde de maniere tres generale la gestion des communications. S?appuyant 
sur sa puissante capacite a developper des logiciels couvrant les besoins les plus 
communs, il a opte pour une strategic reposant sur 1'unification la plus large possible. Sa 
suite logicielle Microsoft Office System peut meme etre integree directement dans les 
applications proprietaries grand public de la firme. 

Cette offre n'a pas vocation a servir uniquement les besoins des particuliers, mais 
s?etend aux besoins professionnels, notamment pour le travail collaboratif en temps reel, 
en mettant 1' accent sur la garantie de transmission des donnees sans interruption intem- 
pestive. 
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Son outil phare pour les communications temps reel en entreprise est LCS (Live 
Communications Server), un sous-ensemble de Microsoft Office System. Parallele- 
ment, Microsoft poursuit et amplifie son offensive dans les services unifies, avec sa 
gamme Live. 

La gamme de services unifies Live 

En 1996, la strategic commerciale de Microsoft n'etait pas vraiment tournee vers le 
reseau Internet. II croyait encore en un reseau purement Windows, The Microsoft 
Network, ayant pour vocation de connecter tous les ordinateurs sous plate-forme 
Windows. Ce n'est done pas le protocole IP qui fut choisi pour federer les communica- 
tions reseau, mais specifiquement et exclusivement le systeme d' exploitation proprietaire 
Windows, tres majoritairement implements sur les postes de travail. Lorsqu'il installait 
Windows 95 sur son poste, l'utilisateur voyait s'afflcher systematiquement l'icone The 
Microsoft Network, censee permettre de relier tous les utilisateurs Windows. Finalement, 
ce reseau Microsoft n' a jamais serieusement concurrence Internet. 

De fa^on analogue, cette meme annee 1996, ce n'etait pas le navigateur de Microsoft, 
Internet Explorer, qui dominait le marche, mais Netscape. Ce dernier, pourtant payant, 
occupait une part de marche d' environ 75 %. Microsoft a alors change radicalement de 
strategic en mettant toute sa puissance technique et commerciale sur Internet. Integree a 
Windows 98, la version 4 du navigateur Internet Explorer a pris de vitesse Netscape et 
s'est imposee comme le nouveau navigateur grand public. Parallelement, le service The 
Microsoft Network disparaissait. 

Le reseau purement Microsoft a laisse place a un service reseau a l'echelle d' Internet, 
dont la denomination MSN (MicroSoft Network) rappelle son predecesseur. Ce service 
reseau regroupe differents services, dont les quatre plus importants sont les suivants : 

• MSN : site Internet, portail et moteur de recherche, qui demeure l'un des plus visite au 
monde. 

• Hotmail : messagerie Internet (webmail), qui s'est egalement vite imposee comme une 
reference. 

• Msn Messenger : client de messagerie instantanee, devenu emblematique pour les 
millions d'internautes qui l'utilisent. 

• Msn Spaces : espace de stockage, ou blog, pour tenir un journal personnel a caractere 
humoristique ou informatif, appuye par des sons, photos ou videos. 

L' ensemble de ces services est accessible aux utilisateurs par le biais d'une authentification 
unique, appelee Passport .Net. 

En 2006, la firme de Redmond, desireuse de rapprocher tous ces services dans une 
gamme unique, a decide de les renommer et d'axer uniformement leur developpement 
vers le Web 2.0. Le nom de code de la nouvelle strategic Microsoft est Live, pour symbo- 
liser l'echange, l'interactivite, la rapidite et le temps reel. Le bouquet de services a done 
pris le nom de WLS (Windows Live Services), et s'est enrichi d'une cinquantaine de 
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nouveaux services estampilles Live (par exemple Windows Live Drive, un outil de stoc- 
kage de donnees en ligne, ou Windows Live Academic Search, un moteur de recherche 
pour universitaires). Quant a l'ancien systeme d' identification Passport .Net, il a ete 
renomme Windows Live ID. 

Les services federes par WLS ont egalement ete tous renommes : MSN est devenu Live, 
Hotmail est devenu Windows Live Mail, Msn Spaces est devenu Windows Live Space, et 
MSN Messenger est devenu WLM (Windows Live Messenger). C'est a ce dernier outil 
que nous nous interessons dans la suite de cette section. 

LCS (Live Communications Server) 

Dans le domaine de l'entreprise, 1' outil de communication temps reel LCS (Live 
Communications Server) est un serveur logiciel qui assure la connectivite aux utilisateurs 
et offre un ensemble de services. II est couple avec un logiciel client, Microsoft Office 
Communicator. 

L'originalite de LCS est de couvrir tous les moyens de communication classiques inte- 
gres au sein d'une meme interface. La gestion de presence des utilisateurs est introduite 
afin de fournir en temps reel un indicateur de disponibilite des interlocuteurs, accole a un 
mecanisme d'alertes sur les changements de statut. 

LCS utilise le standard SIP pour unifier l'ensemble de ces services et permettre l'intero- 
perabilite avec des solutions externes. Windows Web Live Meeting, dedie aux conferen- 
ces en temps reel, offre la possibilite d' organiser des reunions interactives, avec jusqu?a 
deux mille intervenants, en partageant voix, video, texte, fichiers et meme tableau blanc. 
Pour etre le plus large possible, la plate-forme logicielle est extensible et prevoit la 
compatibility avec les services de messagerie les plus courants. 

WLM (Windows Live Messenger) 

Avec pres de 300 millions d' utilisateurs, WLM est Tun des clients de messagerie les plus 
utilises au monde. La grande nouveaute de WLM reside dans la possibilite d'appeler des 
utilisateurs sur le reseau telephonique traditionnel (fixe ou mobile). Pourvu de cette fonc- 
tionnalite, 1' aff rontement avec Skype, qui, de son cote, revendique le plus grand nombre 
d' utilisateurs a sa solution de ToIP logicielle, semble inevitable. 

Les sections qui suivent presentent quelques specificites notables de WLM. 

Un protocole proprietaire et ferme 

Le systeme protocolaire utilise dans WLM est proprietaire. Appele MSNP (Mobile 
Status Notification Protocol), il fonctionne sur une couche de transport TCP avec le 
port 1863. 

Publie sous forme de draft en 1999 dans sa version 2, MSNP a beaucoup evolue et en est 
a sa version 14. Ce systeme est totalement ferme, et seuls des analyses des flux entrants 
et sortants ou des partenariats technologiques permettent d'envisager des interactions. 



Pratique de la TolP 



Parte II 



L' architecture generale de WLM est centralisee. Les serveurs Microsoft assurent a eux 
seuls renregistrement de tous les abonnes, avec leurs statuts et leurs pseudonymes. En 
changeant d'ordinateur, ces derniers conservent a la fois leur liste de contacts et le 
dernier pseudonyme qu'ils ont choisi. 

Toutes les communications textuelles sont egalement centralisees et transitent par les 
serveurs Microsoft. Les utilisateurs ne sont done pas mis en relation directement, sauf 
s'ils decident d'initier un transfert de fichier ou une communication audio ou video, 
auquel cas les flux de donnees sont trop volumineux pour transiter par les serveurs 
Microsoft et ces derniers se contentent de faire connaitre aux correspondants leur adresse 
IP respective. 

Longtemps disponible uniquement sous Windows, WLM est depuis peu implements sur 
MacOS X. Cette version ne dispose cependant pas de toutes les fonctionnalites de son 
equivalent Windows, et la video fait notamment defaut. 



Utiliser WLM 



Pour utiliser WLM, il faut telecharger le logiciel a 1' adresse www.windowslivemessenger.fr. A 
l'execution, l'interface du logiciel invite l'utilisateur a s'authentifler en saisissant son 
identiflant unique et le mot de passe associe. 

Si l'utilisateur ne dispose pas encore d'un compte, il lui sufflt de cliquer sur Creer un 
nouveau compte. Ce compte est appele Windows Live ID. 

Avant meme d'etre connecte, il est possible de selectionner le statut avec lequel on 
souhaite se connecter. C'est notamment utile pour le statut Invisible, qui permet de ne se 
connecter que pour savoir qui est en ligne et eventuellement de discuter avec certains 
contacts tout en restant invisible des autres. 

Une fois l'authentification effectuee, on accede a la fenetre principale (voir figure 10.1), 
plus sobre et epuree que celle de Skype. 



Figure 10.1 

Fenetre principale de WLM 
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Pour personnaliser cette interface, il faut faire apparaitre la traditionnelle barre de menus. 
Dans un souci d'ergonomie, cette barre est masquee par defaut et s'affiche en cliquant sur 
la fleche descendante, en haut a droite de l'interface. En selectionnant les menus Outils et 
Options, on accede a la configuration des preferences. 

Le service de telephonie Windows Live Call 

WLM inclut la possibility de telephoner de fa^on purement IP entre internautes, mais sa 
principale nouveaute reside dans la possibilite de passer des appels d'un PC vers un tele- 
phone fixe ou mobile. Pour proposer ce service, Microsoft s'est associe a l'operateur 
americain MCI, qui a ete rachete par Verizon Communications, le deuxieme operateur 
telephonique americain. 

L'acces au service se fait en selectionnant Appeler puis Un autre telephone dans le menu 
Actions (voir figure 102). 



Figure 10.2 

Fonctionnalites de WLM 
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L'interface du service Windows Live Call invite alors l'utilisateur a acheter des credits de 
communication lui permettant d'emettre des appels. Une fois 1' achat effectue, la fenetre 
illustree a la figure 10.3 permet de composer le numero du correspondant a joindre. 



Figure 10.3 

Appel avec Windows Live Call 
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L'utilisateur a la possibility d'emettre des appels a destination de plus de 220 pays a des 
tarifs variables, plus avantageux que ceux proposes par les operateurs de telephonie, et 
avec une excellente qualite sonore. 

A la difference de Skype, Windows Live Call ne fournit pas d' option pour disposer d'un 
numero de telephone standard aux clients. Autrement dit, seuls les appels sortants sont 
envisageables avec la telephonie standard, et il n'est pas possible de recevoir des appels 
provenant de telephones standards. Par ailleurs, en telephonie purement IP, il n'existe pas 
de messagerie vocale associee au compte. 

Peripheriques compatibles 

Pour etendre davantage son reseau de diffusion, Microsoft a mis en place des partenariats 
integrant le logiciel WLM dans des telephones traditionnels. Sans avoir besoin d'allumer 
son ordinateur, il devient possible grace a ces combines d'appeler et de recevoir des 
appels avec des contacts de sa liste WLM comme avec n'importe quel autre contact du 
reseau RTC. Philips est devenu le premier partenaire europeen a distribuer un tel tele- 
phone. 

II existe une version de WLM pour le systeme d' exploitation Windows Mobile de Micro- 
soft, destine aux telephones mobiles intelligents, ou SmartPhones, et aux assistants 
personnels (PDA). Grace a la convergence entre mobiles et PC, les operateurs de telepho- 
nie proposent egalement WLM sur des telephones portables, notamment France Tele- 
com, avec son offre specifique Orange Messenger by Windows Live, Bouygues Telecom, 
avec le service iMode, ou l'operateur virtuel Ten. 

Dans un souci d' extension, Microsoft commence egalement a ouvrir ses API en propo- 
sant des kits de developpement pour les programmeurs independants souhaitant faire 
evoluer le logiciel WLM. 

Alter plus loin avec WLM 

Pour se distinguer de ses concurrents, WLM va plus loin que la messagerie instantanee et 
la telephonie sur IP, en proposant un ensemble de fonctionnalites specifiques. Cette 
section presente quelques-unes d'entre elles. 

Integrer WLM sur ses pages Web 

WLM permet 1' integration de ses principales commandes dans des pages Web grace a 
des balises specifiques, qui evitent d'avoir a saisir manuellement l'identifiant d'un 
correspondant. L'internaute ne peut toutefois executer ces commandes que s'il utilise le 
navigateur Internet Explorer. De plus, en cliquant sur un lien Web, l'internaute actionne 
une commande qui ne peut etre prise en charge que par le logiciel WLM. II doit done 
necessairement avoir installe et lance le logiciel. 
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Le tableau 10.1 recapitule les principales commandes disponibles (la partie 
identifiant_email doit etre remplacee par l'identiflant reel de l'utilisateur WLM 
concerne). 

Tableau 10.1 - Balises HTML pour lancer une commande WLM sur une page Web 



Action 

Ajouter un contact dont I'identifiant est i denti f i ant_emai 1 

Demarrer une conversation textuelle avec un contact dont 
I'identifiant est i denti f i ant_emai 1 

Envoyer une invitation pour demarrer une conversation audio 
avec un contact dont I'identifiant est i denti f i ant_emai 1 

Envoyer une invitation pour demarrer une conversation video 
avec un contact dont I'identifiant est i denti f 1 ant_emai 1 



Code 

msnim:add?contact= i denti fiant_email 
msnim:chat?contact= 1 denti fiant_email 

msnim: voice?contact= i denti fiant_emai 1 

msnim:video?contact= i denti fiant_email 



Par exemple, pour generer un lien permettant d' ajouter un contact dont le nom est 
mon_identijiant@hotmail.fr, il faut inserer dans le code Web de sa page la balise 
suivante : 

|<a href="msnim:add?contact= mon_i denti fiant@hotmail .fr"> 
Cliquer ici pour m'ajouter dans vote liste de contacts WLM ! 
</a> 

En cliquant sur ce lien, l'internaute declenche un message du logiciel WLM lui demandant 
la confirmation d'ajout du contact. 

Afficher des images de ses contacts 

Par defaut, l'interface n'affiche que de petites icones a cote de chaque contact. Pour 
remplacer ces icones par 1' image choisie par ses correspondants, il suffit de cliquer sur le 
bouton Gerer vos contacts, a droite du champ de recherche des contacts (voir 
figure 10.4), puis de selectionner Afficher les details. L' image du contact s'affiche en 
taille reduite. 



Figure 10.4 

Affichage de I 'image 
d'un contact 
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Windows Live Contacts 

WLM propose un outil de gestion avancee des contacts, appele Windows Live Contacts, 
dont le fonctionnement repose sur renrichissement volontaire de chacun des utilisateurs. 

Par clic droit sur la zone textuelle ou figure son pseudonyme (juxtapose a son image 
personnelle), un menu contextuel propose 1' option Partager mes coordonnees. Dans la 
page Web qui s'afflche, l'utilisateur peut renseigner ses propres informations. Ces 
dernieres etant confldentielles, il est possible de restreindre leur diffusion a des groupes 
de personnes ou a des personnes en particulier parmi la liste des contacts WLM afflchee 
a la section Autorisation de la page Web. 

Inversement, pour connaitre les informations relatives a un contact, il suffit de selection- 
ner ce contact par clic droit puis de choisir Modifier un contact. Toutes les informations 
sur ce contact s'afflchent alors. 

Ajouter un nom et mettre a jour les informations de ses contacts 

Les contacts peuvent se presenter de fa^on ambigue. Par exemple, deux personnes ayant 
le meme prenom pour pseudonyme ne sont distinguables qu'en examinant leur adresse 
de messagerie. Pour permettre d' identifier plus simplement un contact, WLM propose 
une fonction d' alias. 



Figure 10.5 

Mise a jour d'un contact 
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Pour mettre en oeuvre un alias, il sufflt de selectionner un utilisateur par clic droit et de 
choisir la fonction Aj outer un surnom dans le menu deroulant (voir figure 10.5). De cette 
maniere, quels que soient les changements de pseudonyme effectues, les contacts sont 
facilement identiflables. 

Lorsqu'un contact change son image, la modification n'est pas immediatement refletee 
chez les correspondants et n'est mise a jour qu'au moment ou le contact se connecte. 
II est possible de forcer cette mise a jour afin qu'elle s'effectue a intervalle regulier. II sufflt 
de selectionner un contact par clic droit puis de selectionner 1' option « Recevoir les coor- 
donnees mises a jour du contact », comme illustre a la figure 10.5. 

Exporter et importer sa liste de contacts 

Pour diverses raisons, un utilisateur peut vouloir creer un nouveau compte. Pour cela, il 
doit obtenir un nouvel identiflant de connexion puis inserer un a un tous ses anciens 
contacts. Pour eviter cette saisie fastidieuse, WLM offre la possibilite d'exporter et 
d' importer sa liste de contacts. 

II sufflt pour cela de selectionner « Enregistrer les contacts Messenger » dans le menu 
Contacts. Un document portant l'extension ctt (pour contacts) est alors genere. Ce docu- 
ment doit etre stocke afin de permettre l'importation future de ses contacts. L' exportation 
se fait de maniere tout aussi simple dans le menu Contacts a l'aide de 1' option « Importer 
des contacts Messenger ». La fenetre qui s'ouvre invite l'utilisateur a specifier le chemin 
ou se trouve le flchier de contacts portant l'extension ctt. 

Cette fonctionnalite permet en outre de partager sa liste de contacts avec d'autres 
personnes, par exemple un groupe d'amis communs ou un repertoire d'entreprise. En 
ce cas, l'importation ne peut etre selective, et il faut accepter tous les contacts de la 
liste ou aucun. 

II est neanmoins possible d'afflner ce processus et de ne selectionner que certains 
contacts en recourant a une petite astuce. Le document portant l'extension ctt est en 
realite un simple flchier texte editable et modifiable dans n'importe quel editeur de texte. 
II sufflt de le selectionner par clic droit, de choisir Ouvrir avec dans le menu contextuel et 
de preciser 1' editeur de texte de son choix, WordPad ou Word. II devient ainsi possible de 
supprimer des contacts ou d'en ajouter manuellement. 

L'important dans l'edition de ce flchier est de respecter scrupuleusement sa syntaxe. 

Utilisateurs bloques et hors connexion 

Un utilisateur ne peut jamais savoir si l'un de ses contacts l'a bloque. II est simplement 
vu comme etant hors connexion, rendant impossible toute tentative de communication. 
De la meme maniere, le statut d'un utilisateur invisible est confidentiel, et ses contacts 
ont seulement l'impression que celui-ci est deconnecte. 

En revanche, un utilisateur bloque par un autre utilisateur est souvent retire de la liste 
des contacts de ce dernier. Or cette action peut etre detectee manuellement a tout 
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moment. II suffit de selectionner le menu Outils, puis de choisir Options et d'ouvrir 
l'onglet Confidentiality, qui comporte la section Listes de contacts illustree a la 
figure 10.6. Le bouton Afficher permet de voir la liste des contacts chez qui Ton figure 
en tant que contact. Par inversion, on peut en deduire les contacts chez qui Ton ne 
figure pas. 

F '9ure 10.6 Listes de contacts 



Option de la liste des contacts Consulter la lists des utilisateurs m'ayant ajoute a leurs contacts [ Afficher. .. | 

[^1 M'avertir lorsque quelqu'un m'ajoute a sa liste de contacts 

Ajouter un robot intelligent dans sa liste de contacts 

La societe Conversagent a con^u pour WLM un programme intelligent capable de repon- 
dre a des questions en exploitant la base de donnees encyclopedique Encarta de Micro- 
soft. Ce robot, appele Encarta Reponses Instantanees, a la particularity de repondre 
instantanement a des questions posees en langage naturel. 

Ce type d'outil est decrit par Conversagent comme un ASA (Automatic Service Agent). 
Son originalite reside dans le fait qu'il est accessible sous la forme d'un contact WLM 
et que ses reponses sont fournies de maniere concise dans une fenetre de messagerie 
standard. 

Pour disposer du robot en langue franchise, il suffit d'ajouter a sa liste de contacts l'iden- 
tifiantfr.encarta@botmetro.net. En double-cliquant sur ce contact, la fenetre de message- 
rie apparait, et il est possible de poser toutes sortes de questions, meme saugrenues. 
Quelques exemples de questions-reponses sont donnees a la figure 10.7. 

Le service est predispose a repondre a plusieurs categories de questions, mais il 
bloque bien souvent sur des questions a priori simples, ce qui le relegue davantage 
dans la categorie gadget, du moins jusqu'a sa maturite, tout en meritant malgre tout 
un detour. 

Le robot et ses reponses abregees sont accessibles gratuitement. Pour completer les 
reponses fournies par le robot, ce dernier invite l'utilisateur a utiliser optionnellement 
la version en ligne d' Encarta. Dans ce cas, un volet complementaire a droite de la 
fenetre de discussion s'ouvre pour afficher les reponses pertinentes du site Encarta. 
Cet acces est toujours gratuit, mais certains liens proposent l'acces a Encarta 
Premium, qui est la base la plus complete de 1' encyclopedic, et necessite un abonnement 
payant. 

II existe bien d'autres robots assignes a differentes fonctions, mais la presque totalite 
d'entre eux converse en langue anglaise. smarterchild@hotmail.com est probablement 
l'un des plus aboutis du moment. Evolutif, il apprend au fur et a mesure des conversa- 
tions, en fonction de ce qui lui est dit. Pour inciter au developpement de robots de ce 
type, Microsoft a lance un concours recompensant les robots les plus performants 
(Robots Contest). 
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Figure 10.7 

Exemples de questions -rep onses au robot d'Encarta 



Censure automatique 

Un peu par hasard, les utilisateurs de WLM ont decouvert que certains mots etaient pros- 
crits lors des communications avec le logiciel. II est par exemple impossible d' envoy er 
un message contenant les mots download.php, gallery.php, profile.php ou .src et .pif. 

Meme si le message contient d'autres mots, il est refuse par le serveur, et le recepteur pas 
plus que l'emetteur ne sont informes qu'un message n'a pu etre transmis. 

Dans le meme genre, si, lors d'une conference avec plusieurs intervenants, une personne 
utilise un de ces mots, elle se voit exclue de la conference par un message pour le moins 
surprenant : « Vous avez momentanement des problemes de reseau. Vous n'etes plus 
dans la conversation. » 

La raison invoquee par Microsoft pour justifler ce comportement etrange est la protection 
de l'utilisateur. Ce type de message est en effet frequemment utilise par les hackers pour 
inciter l'utilisateur a cliquer sur un lien, lequel lance insidieusement sur le poste client un 
virus ou un cheval de Troie. Pour proteger les postes utilisateur et eviter que le logiciel ne 
soit vecteur de telles attaques, Microsoft bannit l'utilisation des termes juges sensibles. 
Reste que la contrainte subsiste pour les usages licites. 

II est en tout cas dommage que l'utilisateur ne puisse deselectionner cette option de 
protection envahissante. D'autant plus que Microsoft n'a pas communique la liste des 
mots interdits. En realite, tous les flux de communication textuelle etant relay es vers les 
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serveurs de Microsoft, cette liste de mots peut etre modifiee a tout moment. Par ailleurs, 
la centralisation des communications peut faire redouter aux plus sceptiques l'enregistre- 
ment de toutes les communications privees a des fins de profilage des utilisateurs, theori- 
quement possible, quoique totalement dementi par Microsoft. 

Web Messenger sur interface Web 

Les fonctionnalites de base de WLM sont egalement disponibles sur une interface Web, 
appelee Web Messenger, sans avoir a telecharger le logiciel. II suffit de se rendre a l'URL 
http://webmessenger.msn.com. Ce service est disponible sur Internet Explorer et Mozilla 
Firefox. 

Pour en beneficier, il est necessaire d'autoriser les fenetres pop-up pour lancer l'inter- 
face. Cette derniere ne propose que des fonctions reduites, essentiellement la messagerie 
instantanee entre utilisateurs, et il n'est pas possible de converser vocalement ni 
d'envoyer des fichiers. 

Le service s'avere surtout utile dans les cas ou 1' installation du logiciel WLM est impos- 
sible. C'est le cas, par exemple, lorsqu'un utilisateur se trouve sur un ordinateur qui n'est 
pas le sien ou qu'il ne possede pas les droits d' administration sur ce poste ou encore qu'il 
n'utilise pas un systeme d' exploitation compatible avec le logiciel. Par ailleurs, dans un 
reseau filtrant et bloquant les connexions WLM, le Web Messenger a de fortes chances de 
passer, car il ne repose que sur des connexions Web classiques. 

Extensions et ameliorations de WLM par des programmes tiers 

Plusieurs tentatives d' amelioration du logiciel WLM ont ete proposees par des parti- 
culiers, qui sont le plus souvent utilisateurs et developpeurs et diffusent leurs creations 
gratuitement, en echange parfois de messages publicitaires. 

Ces ameliorations se presentent sous la forme de petits programmes a telecharger, qui 
etendent les fonctions de WLM et lui ajoutent des options. II existe quantite d'extensions 
de ce type, chacune apportant son lot d' options complementaires. 

L'une de ces extensions parmi les plus connues est Windows Plus! Live. Gratuite, simple 
et disponible en fran^ais a l'adresse www.msgpluslive.net, elle existe depuis plusieurs annees, 
et bien des ameliorations qu'elle a apportees ont ete progressivement integrees dans la 
mouture officielle du logiciel de Microsoft. Parmi les fonctionnalites innovantes de cette 
extension, signalons la possibilite de lancer plusieurs instances de WLM, de regrouper 
toutes les conversations dans une fenetre unique a onglets, de modifier l'apparence des 
fenetres, de surveiller des evenements, tels que le changement de statut d'un contact, 
d'effectuer des substitutions de messages textuels ou encore d'interroger un compte de 
messagerie externe POP3. 

Lors de 1'installation de ce logiciel, il est propose a l'utilisateur de choisir l'option 
« Installer les sponsors ». II est recommande de desactiver cette option, car ces « spon- 
sors » sont en realite bien souvent des spywares, petits logiciels espions qui epient 
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l'activite des utilisateurs sur leur poste de travail et forcent l'affichage de bandeaux 
publicitaires. 

Apres 1' installation du logiciel, une configuration de base est proposee automatiquement 
en redemarrant WLM. La configuration complete peut s'effectuer a tout moment via 
V option Preferences du menu Plus!. Notons que les developpeurs peuvent utiliser cette 
extension et 1'enrichir par des scripts complementaires (via le menu General puis la 
section Scripts). 

Parmi les autres extensions de ce type, signalons MessengerDiscovery Live, disponible a 
l'adresse http://live.msgdiscovery.com et similaire a Messenger Plus! Live ou, plus originale, 
Fake Webcam, qui remplace la diffusion d'une video par webcam par celle d'une video 
de son choix (www.fakewebcam.com). 

Yahoo! Messenger 

Avec pres de 90 millions d'adeptes dans le monde, Yahoo! Messenger, la messagerie 
instantanee de Yahoo!, est tres proche de la messagerie de Microsoft. 

Tous deux ont fonde une grande partie de leurs developpements sur le Web (en integralite 
dans le cas de Yahoo!) et sont en concurrence sur plusieurs services. Leur moteur de 
recherche et leur messagerie Web respectifs ont ete largement couronnes de succes. Dans 
les deux cas, le logiciel de messagerie instantanee fait office de portail vers leurs propres 
services mais aussi un ensemble de partenaires qui proposent des services souvent 
pay ants. 

Plus etonnante, l'ergonomie des interfaces offertes dans les deux logiciels est frap- 
pante de ressemblance : barre de recherche de contacts, barre de recherche Web, barre 
d'outils, barre de publicite, liste de contacts et meme photos sont situees aux memes 
emplacements. 

Utilisation 

Chose rare, les utilisateurs d' ordinateurs Mac et UNIX n'ont pas ete oublies par le logi- 
ciel propose par Yahoo!. Pour les possesseurs de PC sous Windows, le client de Yahoo! 
Messenger est disponible a l'adresse http://fr.messenger.yahoo.com. Pour les autres plates- 
formes, il faut se tourner vers la version anglaise du site, aux adresses http://fr.messen- 
ger.yahoo.com/mac.php, pour MacOS 8/9/X, et http://fr.messenger.yahoo.com/unix.php, pour PC 
sous UNIX. 

Nous ne detaillons dans les sections suivantes que la version Windows. 

L' installation de Yahoo! Messenger est plus delicate que celle de WLM. Non seulement 
le logiciel est plus volumineux, mais il peut aussi se reveler particulierement intrusif si 
Ton n'y prend garde. 

En effet, apres avoir telecharge l'installeur du programme, il faut proceder avec prudence 
dans le choix des options. Deux possibilites sont offertes : une installation typique et une 
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installation personnalisee. Si Ton choisit l'installation typique, la page d'accueil de son 
navigateur Web devient celle du portail yahoo.fr, et le moteur de recherche par defaut 
(accessible par la touche F3 sur Internet Explorer) devient celui de Yahoo!. II est done 
vivement recommande de preferer l'installation personnalisee, qui affiche clairement les 
elements a installer et permet de desactiver les choix inopportuns. 

Une fois l'installation effectuee, le logiciel s'ouvre sur la page invitant l'utilisateur a 
s'identifier avec son identifiant de compte Yahoo! et son mot de passe associe ; la 
connexion s'effectue alors, donnant acces au logiciel. 

Un logiciel portail 

L' interface principale de Yahoo! Messenger est particulierement riche en fonctionnalites. 
Hautement personnalisable, le logiciel se distingue de ses concurrents par l'utilisation 
d'un mecanisme de plug-in, permettant d'ajouter des fonctionnalites au produit de base. 

La figure 10.8 illustre l'interface standard par defaut. 



Figure 10.8 
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Les plug-in sont situes au bas de l'interface, juste au-dessus de la barre de recherche de 
Yahoo!. On y trouve 1' acces a des breves d'actualites, a de la musique en ligne, a des jeux 
en solo ou en reseau, a des blogs, ainsi qu'aux cours de la Bourse. 

Ces plug-in sont accessibles par simple clic et s'ouvrent dans un nouveau panneau de 
controle, sur le cote du logiciel. lis sont configurables (en cliquant sur le bouton Plugins). 
Le client logiciel de Yahoo! se distingue par cette personnalisation de l'interface, laquelle 
devient bien davantage qu'une plate-forme de communication et fait office de portail vers 
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rinformation en continu, la meteo, l'actualite specialisee, en passant par la musique en 
ligne, les resultats sportifs, etc. 

Le statut avec lequel l'utilisateur est connecte est affiche en haut, en regard de sa photo 
ou image. Pour le modifier, il sufflt de cliquer sur la fleche descendante et de selectionner 
celui qui convient ou d'en creer un nouveau. 

Juste en dessous de la photo, une barre d'outils donne acces aux fonctions les plus 
courantes suivantes : 

• Ajout de contacts. 

• Affichage de la liste de contacts dans le panneau central du logiciel. 

• Modification du panneau central pour le remplacer par le carnet d'adresses listant 
1' ensemble des contacts. 

• Acces par lien direct a la messagerie Yahoo! associee au compte courant. 

• Acces a son repondeur de messages audio. 

• Acces a Yahoo! 360°, le service de blog de Yahoo!. 

La barre de saisie alphanumerique situee en dessous de la barre d'outils simplifie les 
mises en relation par une aide a la saisie. A defaut de parvenir a interpreter les caracteres 
saisis, elle permet de lancer une recherche de texte dans le moteur de Yahoo!. 

Dans la liste des contacts affichee dans la zone centrale, l'icone de chaque contact 
precede les pseudonymes correspondants. Le statut des contacts, s'il est autre que Dispo- 
nible, est mentionne a la suite des pseudonymes. 

Fonctionnalites evoluees 

En plus du mecanisme de plug-in, Yahoo! Messenger offre des fonctionnalites evoluees, 
parmi lesquelles les services gratuits suivants : 

• Creation d'avatars. Les avatars definissent l'image qui est affichee a cote de son pseu- 
donyme et qui est diffusee aux contacts. 

• Gestion des conferences. Plusieurs correspondants peuvent se joindre a un salon de 
discussion. L' invitation a rejoindre la conference s'effectue par la fonction « Inviter 
des amis a une conference » du menu Actions. 

• Transfert de fichiers. Des documents de taille tres importante (pouvant atteindre le 
gigaoctet) peuvent etre echanges simplement en depla^ant les documents dans la 
fenetre de messagerie d'un contact. La fonction de transfert est aussi disponible par le 
biais de la fonction « Envoy er un fichier » du menu Actions. 

• Visiophonie. En plus d'echanger des messages textuels et audio, les conversations 
peuvent ajouter la video si l'utilisateur dispose d'une webcam. La gestion des appels 
video se fait soit directement dans la fenetre de dialogue par le bouton Webcam, soit 
par le biais de la fonction « Inviter des contacts a voir ma webcam » du menu Actions. 
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La fonction « Afficher la webcam » du meme menu sollicite l'affichage de la webcam 
d'un contact selectionne. 

Telephoner avec Yahoo! Messenger 

Parmi les facettes remarquables du client Yahoo! Messenger, le service de telephonie est 
exploitable pour appeler aussi bien des utilisateurs equipes du logiciel (telephonie IP 
pure) que des telephones standards. 

Les peripheriques audio sont generalement reconnus automatiquement, et aucune confi- 
guration particuliere n'est necessaire. En cas de conflit ou de probleme audio, les regla- 
ges des parametres audio peuvent s'effectuer par le biais du menu Messenger en selec- 
tionnant Preferences. Dans la liste des categories disponibles qui apparait a gauche de la 
fenetre, la section « Appel et Audio » s'affiche pour donner acces au choix des peri- 
pheriques audio et a un assistant de configuration. 

Avec le logiciel, la telephonie IP pure est accessible simplement et gratuitement par 
differents moyens : 

• Un clic droit sur un utilisateur ouvre le panneau represents sur la partie gauche de la 
figure 10.9. En cliquant sur le bouton symbolisant un telephone, l'utilisateur est invite 
a confirmer qu'il souhaite appeler l'ordinateur de son correspondant. 



Figure 10.9 

Appeler l'ordinateur d'un contact 
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• Un clic gauche sur un utilisateur ouvre le menu deroulant illustre sur la partie droite de 
la figure 10.9, sur lequel on remarque la fonction « Appeler l'ordinateur ». 

• Un clic droit sur l'icone de Yahoo ! Messenger dans la zone d'etat systeme de Windows 
permet de selectionner la fonction « Appeler l'ordinateur », qui presente la liste des 
contacts. 

En selectionnant l'un de ces choix, on ouvre automatiquement une fenetre de dialogue 
avec le contact correspondant, et 1' appel est initie. La barre d'outils de cette fenetre indi- 
que la duree de 1' appel en cours et permet de regler le volume sonore, de mettre 1' appel 
en attente ou de le terminer. 
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Appeler des lignes fixes et portables avec Yahoo! Voice 

Fruit d'un partenariat avec la societe californienne Dialpad, specialisee dans la telepho- 
nie sur IP, et dont elle a fait l'acquisition en juin 2005, Yahoo! propose dans sa nouvelle 
version de telephoner sur des lignes fixes du reseau commute traditionnel. 

Appele Yahoo! Voice, ce service s' utilise comme des credits de minutes de communica- 
tion a acheter par pack. Si l'utilisateur tente d'appeler un telephone sans avoir les credits 
suffisants, il est automatiquement redirige sur une page lui permettant de crediter son 
compte. 

Un appel telephonique peut etre initie des diverses fa^ons suivantes : 

• En selectionnant « Appeler un numero de telephone a partir d'un contact ». 

• En selectionnant « Appeler un numero de telephone » du menu Actions d'une fenetre 
de Yahoo! Messenger. 

• Par le biais du raccourci clavier Ctrl + K. 

• En selectionnant « Appeler un numero de telephone » a partir de l'icone de Yahoo! 
Messenger de la zone d'etat systeme. 

• En saisissant directement un numero de telephone dans la barre situee entre la barre 
d'icones et la liste des contacts. 

Dans tous ces cas, l'appel est lance, et l'internaute voit s'afficher une fenetre semblable a 
celle illustree a la figure 10.10. 
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Figure 10.10 

Appel a partir du service Yahoo! Voice 



Yahoo! Voice propose des tarifs tres competitifs, qui varient selon les distances. Beau- 
coup d' entre eux sont plus interessants que ceux du client dedie de Windows Live 
Messenger. La qualite audio est globalement bonne, meme si des coupures intempestives 
peuvent survenir occasionnellement. 
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Comme WLM, Yahoo! ne propose aucun service fournissant un numero d'appel entrant 
pour etre joignable a partir d'un reseau telephonique RTC. En revanche, les appels 
entrants provenant du reseau IP peuvent etre distingues selon 1' appelant. Ainsi, une 
sonnerie particuliere retentit selon l'identite du correspondant qui appelle. 

Repondeur et historique d'appels 

Une fonctionnalite particulierement pratique du Messenger de Yahoo! reside dans la 
possibilite de laisser des messages audio a ses correspondants absents. Ce service est 
totalement gratuit. 

Si un utilisateur tente de joindre un contact qui ne repond pas au bout d'une quarantaine 
de secondes, il est automatiquement redirige vers la messagerie de ce dernier. Un court 
avertissement audio, en fran^ais, invite 1' appelant a laisser un message. La barre d'outils 
de la fenetre de conversation laisse place a la zone de controle du message audio illustree 
a la figure 10.11. Ce message ne doit pas exceder deux minutes. 



Figure 10.11 

Enregistrement d'un message 
vocal 
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La personne appelee est avertie de l'arrivee d'un nouveau message sur 1' interface princi- 
pal de son Messenger par l'icone coloree representant une bobine d' enregistrement qui 
s'active (comme pour la reception d'un nouvel e-mail). Pour consulter ses messages, il 
suffit de cliquer sur cette icone et de consulter les journaux de tous les appels audio qui 
sont sauvegardes. 

L' interface comporte deux volets. Celui de gauche permet de filtrer les appels selon diffe- 
rents criteres. Les messages correspondant au filtre selectionne s'affichent dans le volet 
de droite. La section « Historique des appels » liste 1' ensemble des appels, sans 
distinction. 

II est possible de filtrer cette liste selon des criteres tels qu'une personne, un numero de 
telephone, ou les appels re^us (Appels entrants), emis (Appels sortants), sans reponse 
(Appels manques) et audio (Messages vocaux). 

En selectionnant un message audio dans le volet de droite, les icones de la barre supe- 
rieure deviennent actives et offrent differents moyens de controle du message : lecture, 
avance et recul de 7 secondes, controle du volume sonore, rappel de 1' appelant, envoi 
d'un message instantane, ajout du contact, blocage de l'appelant et enfin suppression du 
message selectionne. 

Dans la partie inferieure gauche de la fenetre, un lien direct donne acces a la page Web 
detaillant la facturation de son compte afin de connaitre l'etat de son credit. 
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Yahoo! Messenger sur un telephone 

A l'instar de Skype et WLM, le logiciel de messagerie de Yahoo! est implements sur 
certains telephones arm d'etre utilisable sans avoir a allumer son ordinateur. 

La liste des contacts de son compte est affichee sur le poste telephonique, et chacun de 
ces contacts est joignable dans les memes conditions tarifaires qu'avec 1' ordinateur 
(gratuite pour les appels sur le reseau IP et tarif Yahoo! pour le reseau telephonique 
commute). 

La figure 10.12 illustre un tel telephone sans fil DECT propose par le constructeur 
Siemens. 



Figure 10.12 

Un telephone integrant Yahoo! 
Messenger 




Estampille Y! Ready, ce telephone a donne lieu a une certification Yahoo!. Celle-ci est 
avant tout un label commercial certifiant que le materiel est compatible avec le logiciel et 
validant son bon fonctionnement. 



Le partenariat Microsoft- Yahoo! 

Yahoo! et Microsoft utilisent des protocoles proprietaries distincts, ce qui ne les rend pas 
interoperables. D'autres systemes de messagerie, tel Jabber, que nous presentons en 
detail au chapitre 11, pronent un modele libre et ouvert, dans lequel chacun est libre de 
choisir son systeme de messagerie et peut communiquer avec un utilisateur ayant choisi 
un autre systeme de messagerie. Ces concurrents reprochent a Skype, Microsoft et 
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Yahoo! d'user de leur suprematie pour contraindre leurs utilisateurs a rester cloisonnes 
dans leur reseau proprietaire respectif. 

Les programmeurs n'ont pas attendu une reaction des grands editeurs pour proposer des 
outils multiprotocoles capables de se connecter sur chacun de ces reseaux. Puisque les 
protocoles en question sont fermes, ces programmeurs ont du user d'ingeniosite pour 
comprendre la logique et les messages utilises dans ces logiciels. Pour cela, ils ont 
procede a une ecoute (sniffing) des communications reseau qu'engendre chacune des 
actions de ces logiciels. Ils en ont deduit les messages a envoyer pour reproduire ces 
actions. 

Un logiciel tel que Wireshark (anciennement Ethereal), gratuit et disponible sous 
toutes les plates-formes courantes, permet une ecoute tres fine et plutot pertinente de 
ces messages. Legalement, si la decompilation du programme lui-meme est interdite 
sans l'accord des ayants droit, rien n'interdit d'analyser les echanges protocolaires a 
des fins de compatibility . Ainsi, dans le cadre du droit a l'interoperabilite, il est parfai- 
tement autorise de proceder a la decompilation des interfaces de communication de 
n'importe quel logiciel, c'est-a-dire d'utiliser un sniffer sur un logiciel afin d'en 
deduire une forme de langage generique qui sera implementee et adaptee dans un 
logiciel tiers. 

Ce mode artisanal echappe au controle des majors de l'industrie et a leur guerre ouverte 
pour imposer leur standard. Pour ces majors, l'utilisation de logiciels tiers dans leur 
propre reseau de messagerie represente une double perte : non seulement le contraignant 
bandeau publicitaire finan^ant le service (et done la maintenance des serveurs) disparait 
dans les logiciels tiers, mais la gamme de services complementaires (telephonie, logos 
personnalises, musique, envoi de SMS, etc.) qu'ils proposent en mode payant, n'est 
souvent plus accessible. 

Conscients de ces difficultes naissantes, Yahoo! et Microsoft, bien que concurrents, ont 
decide de travailler ensemble pour trouver une issue commune. Pour eviter qu'un utilisa- 
teur n' utilise un programme tiers pour se connecter a leur reseau de messagerie, ils ont 
decide, en octobre 2005, d'offrir une couverture plus large en rendant compatibles leurs 
reseaux de messagerie. L'accord a pris effet en aout 2006. 

Un utilisateur de l'un de ces deux logiciels peut done aj outer un utilisateur de la plate- 
forme concurrente de maniere transparente, comme s'il s'agissait de la meme plate-forme. 
Comme l'illustre la figure 10.13, l'ajout d'un nouveau contact dans Yahoo! Messenger 
permet de specifier si ce dernier est un contact Yahoo!, LCS (la messagerie profes- 
sionnelle de Microsoft) ou WLM/MSN. 

Aux duplications de comptes pres (certainement importantes), e'est potentiellement une 
base de donnees d' environ 390 millions de contacts qui peut ainsi circuler entre les deux 
reseaux. En s'alliant, les deux societes creusent ainsi l'ecart avec leurs concurrents, 
notamment avec la messagerie AIM d' AOL, et se placent en position encore plus dominante 
sur le marche. 
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Figure 10.13 

Ajout d'un contact WLM 
a sa liste Yahoo! 



5aisissez I'lD Yahoo! ou I'adresse mail de ce contact : 



Reseau : 



pseudomail@hotmail . com 



Exemple : chatsalot77 

exemple@yahoo.fr 
exemple@hotmail.fr 
exemple@hotmail . com 



Windows Live (M5N) 



Yahoo! Messenger 
LC5 



Ou [ Choisissez un contact de votre Garnet d'adresses. . . 



5i ce contact n'est pas un utilisateur de Yahoo! Messenger, nous vous aiderons 
a lui envoyer une invitation pour qu'il commence a I'utiliser. 



| < Precedent | | 5uivant > J Annuler 



Ce partenariat technologique reste cependant limite, et les conversations audio et 
video sont encore absentes. La compatibilite dans le cadre de ce partenariat a ete 
portee au meme niveau que celle offerte par les logiciels tiers. Nul doute que cette 
association offrira de nouvelles possibilites, au moins pour suivre les avancees des 
concurrents. 



Conclusion 



Compatibilite n'est pas synonyme d'interoperabilite. En depit d'une confusion repandue, 
les deux termes sont differents. La nuance concerne l'utilisation ou non de protocoles 
standards. 

La compatibilite permet la gestion de plusieurs produits utilisant des protocoles diffe- 
rents. Elle fournit les outils pour permettre a ces derniers de communiquer entre eux par 
un mecanisme de traduction d'un produit vers un autre. La conversion d'un protocole de 
communication vers un autre est inherente au mecanisme de compatibilite. 

L'interoperabilite est un concept plus general, qui temoigne de bases communes dans le 
protocole de communication choisi par differents produits. II n'y a pas de traduction d'un 
produit vers un autre, puisque tous deux utilisent les memes specifications protocolaires. 
Pour etre interoperables, les produits doivent s'appuyer sur un protocole ouvert et stan- 
dardise. 
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Ce n'est pas le cas des logiciels de messagerie de Yahoo! et de Microsoft, dont les proto- 
cols sont proprietaries et fermes. Leur partenariat releve done de la compatibilite et non 
de l'interoperabilite. 
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Jabber et Google Talk 



Jabber est une plate-forme libre developpee pour assurer l'interoperabilite des logiciels 
de messagerie instantanee et federer les reseaux de messagerie autour de normes communes. 

Comme la ToIP est devenue le pendant de la messagerie instantanee, Jabber a etendu son 
modele pour traiter la gestion des flux multimedias. 

Google s'en est largement inspire et a participe a l'elaboration de protocoles de signali- 
sation de la voix permettant de proposer un client de messagerie et de telephonie reposant 
sur Jabber en rupture avec tous les autres clients. 



Jabber 



L'approche de Jabber en matiere de messagerie instantanee et de telephonie se distingue 
de celle de ses concurrents en ce qu'elle se rapproche du courrier electronique. 

Ses utilisateurs peuvent communiquer entre eux independamment de leur client logiciel 
et de leur serveur de traitement. Chacun d'eux reste libre de choisir son serveur, qui lui 
fournit une adresse afin de s'identifier, et d'utiliser le client qu'il souhaite parmi la 
gamme des logiciels compatibles disponibles. La cle de voute de cette plate-forme est 
d'offrir un protocole libre et standardise. 

Jabber definit un ensemble de protocoles qui utilisent des normes communes et ouvertes 
laissant libres 1' implementation et l'ergonomie des logiciels clients tout en garantissant 
l'interoperabilite de leurs communications. II ne s'agit done pas a proprement parler d'un 
logiciel client, ni d'un logiciel serveur, mais plutot d'une plate- forme dediee a la messa- 
gerie instantanee et con^ue pour etre ouverte, rapide, facile a utiliser et a etendre pour de 
nouveaux services, parmi lesquels la telephonie sur IP. 
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Les premieres technologies Jabber ont ete developpees par Jeremie Miller en 1998 et ont 
ete publiees pour la premiere fois en mai 2000 avecjabberd, premiere version du serveur. 
Le nom Jabber vient d'un vieux mot anglais evoquant une discussion rapide et presque 
inintelligible. 

Jabber repose sur le protocole XMPP, qui a ete congu au sein de la communaute libre 
Jabber avant d'etre soumis a 1'IETF pour standardisation et evolution. A ce socle funda- 
mental, peuvent etre ajoutees un ensemble de briques destinees a favoriser revolution du 
protocole de maniere modulaire. Ces ameliorations sont connues sous le nom de XEP 
(Jabber Enhancement Proposals). Leur developpement et maintenance sont geres par la 
JSF (Jabber Software Foundation), creee en 2001. 

Architecture de Jabber 

Jabber innove en proposant un modele distribue dans son approche de la messagerie 
instantanee. 

Dans les principaux protocoles de messagerie instantanee, un serveur unique (eventuelle- 
ment avec redondance pour supporter la charge) gere les communications entre utilisa- 
teurs. A la difference de ce modele centralise, Jabber repose sur un reseau de serveurs qui 
assurent la connectivity entre les utilisateurs. 

Chacun de ces serveurs pris individuellement n'a pas la connaissance de 1' ensemble des 
utilisateurs presents dans le reseau, mais a la capacite d'interagir et de dialoguer avec les 
autres arm d' avoir une vue complete du reseau d' utilisateurs. Ce modele distribue est 
assez proche de celui d' Internet, puisque les serveurs de messagerie et de resolution de 
nom (DNS) fonctionnent de maniere analogue. En cela, Jabber se demarque radicalement 
de ses concurrents proprietaries. 

Jabber repose sur un modele de type client-serveur distinguant les trois types d'entites 
logiques suivants : 

• Clients Jabber. A priori, les clients sont des composants extremement simples. lis sont 
interchangeables, et un utilisateur peut decider du jour au lendemain d'utiliser un autre 
client plus fonctionnel, moins lourd ou tout simplement plus esthetique. 

• Serveurs Jabber. C'est sur eux que repose toute la complexite logique de Jabber. lis ont 
pour tache principale la gestion d'un domaine particulier et permettent la creation a la 
demande de comptes dans le domaine qu'ils gerent. Les serveurs stockent 1' ensemble 
des informations et proprietes associees aux comptes, notamment toutes leurs coor- 
donnees et eventuellement toutes sortes d' informations textuelles complementaires. lis 
fournissent en outre des services pouvant apporter des fonctionnalites innovantes. Pour 
faire communiquer deux utilisateurs associes a deux serveurs differents (et done appar- 
tenant a deux domaines differents), les serveurs Jabber doivent pouvoir communiquer 
entre eux. 
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• Passerelles. Les passerelles permettent de joindre un autre type de reseau de messa- 
gerie instantanee, utilisant un protocole non compatible avec celui utilise par Jabber. 
II s'agit le plus souvent d'une entite logique et non physique prise en charge par le 
serveur, le plus souvent sous forme de modules complementaires. Le terme transport 
est indifferemment utilise a la place de passerelle pour designer cette fonctionnalite. 
Par exemple, si Ton souhaite converser avec des utilisateurs WLM ou Yahoo, des 
passerelles doivent etre mises en place pour assurer la jonction de ces reseaux et les 
communications interreseau. Grace a ces passerelles, tout se passe comme si l'utilisateur 
etait connecte au reseau concurrent de maniere transparente. 

L'avantage immediat de concentrer 1'intelligence sur les serveurs, et non sur les clients, est 
de permettre revolution des protocoles de maniere transparente. Autrement dit, lorsqu'une 
implementation est amelioree et qu'on souhaite en disposer, il n'est pas necessaire de 
mettre a jour tous les clients logiciels distribues. II suffit de reporter les modifications au 
niveau du serveur. Les clients sont automatiquement adaptes, car ils sollicitent un service 
generique dont 1' implementation est laissee a la convenance du serveur. 

Comme l'illustre la figure 11.1, le controle et la securisation des communications des 
utilisateurs peuvent etre geres a un niveau interne avant d'etre generalises a 1' ensemble 
du reseau. Dans le cadre d'une entreprise, toutes les communications peuvent etre prises 
en charge par un serveur de 1' entreprise, assurant, par exemple, les fonctionnalites de 
messagerie instantanee, d'annuaire et de telephonie pour ses utilisateurs, le tout en 
respectant les politiques de securite en cours dans 1' entreprise. 




estelle@dom3 



alain@dom1 



beatrice@dom1 



Figure 11.1 

Le modele decentralise de Jabber 



Jabber permet ainsi de mettre en place un systeme de communication local dans une 
entreprise avec une securisation parfaitement maitrisee. En cas de montee en charge trop 
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importante pour etre supportee par un unique serveur, il est possible d' absorber la charge 
sans provoquer d' interruption de service. II suffit pour cela aj outer d'autres serveurs 
gerant le meme domaine. On parle en ce cas d' architecture clusterisee, chaque serveur 
constituant un nceud et formant globalement un cluster, ou grappe, grace auquel tous les 
noeuds peuvent communiquer entre eux. 

De cette maniere, la montee en charge peut etre definie ulterieurement, sans remettre en 
cause 1' architecture existante. En outre, une architecture clusterisee permet de mettre en 
ceuvre une redondance des noeuds arm de continuer a faire fonctionner un service meme 
en cas de panne d'un des noeuds du cluster. 

En controlant les communications par un serveur interne, une entreprise n'est pas recluse 
pour autant et peut, au prix d'une simple configuration du serveur, se connecter a un autre 
serveur. Cela permet d'etendre les communications a 1' ensemble des utilisateurs geres 
par ces serveurs. 

Le pare de serveurs Jabber pouvant s'agrandir a 1'infini, les communications peuvent 
progressivement relier de nouveaux utilisateurs. L'avantage est que chaque serveur peut 
decider de communiquer avec des serveurs bien determines, qu'il s'agisse de sites 
distants d'une entreprise ou de serveurs de confiance, securises et reconnus. 

XMPP (extensible Messaging and Presence Protocol) 

Le standard XMPP est un protocole extensible de messagerie et de presence con^u par la 
communaute Jabber pour formaliser l'echange de flux de messages a contraintes temps 
reel. 

XMPP est a Jabber ce que le protocole HTTP est au Web. II a pour vocation d?unifier 
autour de son langage l'ensemble des protocoles de messagerie instantanee. Comme 
son nom l'indique, la premiere application de ce protocole concerne la messagerie 
instantanee et le service de presence. Mais le protocole ne se reduit pas a cela et couvre 
de nombreuses autres applications, comme le transfert de fichiers ou la gestion de la 
voix. 

Le protocole XMPP s'appuie sur des communications en langage textuel XML, ce qui lui 
confere une grande souplesse d' utilisation sur Internet et facilite sa comprehension. Le 
document de reference pour le protocole XMPP est la RFC 2779 (Instant Messaging/ 
Presence Protocol Requirements), ecrite en fevrier 2000, qui pose les bases de specifica- 
tions pour les protocoles de messagerie et de presence. Le protocole XMPP a ete norma- 
lise et est maintenu par 1'IETF. II a ete decrit en octobre 2004 par quatre RFC, reperto- 
riees de 3920 a 3923 (voir le tableau 11.1). 

Son principal concurrent est le protocole SIMPLE (SIP for Instant Messaging and 
Presence Leveraging Extensions), soutenu par Microsoft et egalement propose par 
1'IETF comme une application de SIP aux systemes de messagerie instantanee. 
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Tableau 11.1 - RFC decrivant le protocole XMPP 



RFC 

RFC 3920 : extensible Messaging and Presence 
Protocol (XMPP): Core 



RFC 3921 : extensible Messaging and Presence 
Protocol (XMPP): Instant Messaging and Presence 



RFC 3922 : Mapping the extensible Messaging and 
Presence Protocol (XMPP) to Common Presence 
and Instant Messaging (CPIM) 



RFC 3923 : End-to-End Signing and Object 
Encryption for the extensible Messaging and 
Presence Protocol (XMPP) 



Description 

La RFC 3920 explicite les fonctionnalites elementaires du protocole 
XMPP, en particulier la connexion entre les entites et I'echange de mes- 
sages entre les clients et les serveurs ainsi qu'entre serveurs. Les com- 
munications entre les serveurs assurent le partage des identites et 
profils des utilisateurs. Deux serveurs appartenant a deux entreprises 
differentes peuvent ainsi communiquer entre elles et partager les infor- 
mations relatives aux comptes de leurs utilisateurs. Ces derniers peu- 
vent communiquer entre eux. De maniere generale, on peut imaginer 
qu'au prix d'une simple configuration, tous les serveurs exploitant XMPP 
et ne dependant pas forcement d'une meme organisation puissent inte- 
ragir et echanger leur base de donnees d'utilisateurs. 

La RFC 3921 s'interesse aux applications de messagerie instantanee et 
de presence. Ces deux applications sont caracteristiques du protocole 
XMPP, mais non exclusives. La RFC explique notamment la gestion des 
listes de contacts et les possibilites de bloquer des contacts dans la liste. 

La RFC 3922 explique comment faire la jonction entre les messages 
des protocoles XMPP et CPIM. CPIM est un protocole issu du groupe de 
travail IMPP (Instant Messaging and Presence Protocol) de I'lETF, qui 
vise a mettre en place une plate-forme d'interoperabilite entre les mes- 
sageries instantanees et les systemes de presence. C'est un modele 
abstrait auquel le protocole XMPP peut s'integrer. La RFC se propose 
d'etablir des relations entre un service utilisant XMPP et un autre n'utili- 
sant pas XMPP mais respectant le modele general IMPP. Cette interac- 
tion sollicite la participation d'une entite logique chargee d'effectuer la 
translation d'un message d'un protocole (XMPP ou CPIM) en un mes- 
sage equivalent de I'autre protocole (XMPP ou CPIM). 

La RFC 3923 detaille les methodes de signalisation de bout en bout et 
les mecanismes permettant la securisation des messages et des don- 
nees manipulees par XMPP. 



XEP (XMPP Enhancement Proposals) 

Les RFC 3920 a 3923 definissent les fondements du protocole XMPP. Leur implementa- 
tion en totalite est done en principe indispensable pour le bon fonctionnement de 1' infras- 
tructure deployant XMPP. Comme indique precedemment, des ameliorations peuvent 
toutefois etre proposees grace aux XEP (XMPP Enhancement Proposals), anciennement 
appelees JEP (Jabber Enhancement Proposals). 

Ces propositions enrichissent le protocole de base en specifiant formellement des ajouts 
fonctionnels. Elles sont a considerer comme des extensions et ne sont par consequent pas 
indispensables. Chaque serveur est libre de les implementer ou non, selon les services 
que 1'administrateur souhaite proposer a ses utilisateurs. De meme, les clients peuvent 
supporter certaines XEP et pas d'autres. Tous les clients et serveurs ne disposent done 
pas des memes caracteristiques et possibilites. 
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Le tableau 11.2 recapitule les principales fonctionnalites complementaires proposees 
dans les XER 

Tableau 11.2 - Principales fonctionnalites complementaires des XEP 



XEP 


Fonctionnalite 


XEP-0016 


Gestion des contacts prives 


XEP-0030etXEP-0128 


Decouverte de services dans le reseau 


XEP-0045 


Conference entre plusieurs utilisateurs 


XEP-0080 


Geolocalisation des utilisateurs 


XEP-0084 


Gestion des avatars 


XEP-0096 


Gestion du service de transfert de fichiers 


XEP-0107 


Gestion des humeurs des contacts (I'indication d'une humeur est donnee directe- 
ment par un utilisateur et peut se refleter, par exemple, par une image, un smiley, 
une couleur, etc.). 


XEP-0116 


Cryptage des sessions 


XEP-0126 


Gestion du statut invisible 


XEP-0127 


Alertes et notifications a I'utilisateur d'evenements specif iques 


XEP-0136 


Archivage des messages 


XEP-0154 


Gestion des prof i Is d'utilisateurs 


XEP-0159etXEP-0161 


Gestion du SPIM (Spam Over IM), ou Spam sur messagerie instantanee, incluant 
les mecanismes de blocage et les journaux 


XEP-0166 


Gestion des flux multimedias (Jingle) 


XEP-0167 


Description des formats audio supportes 


XEP-0172 


Gestion des pseudonymes 


XEP-0180 


Description des formats video supportes 



II existe pres de 200 XEP, avec des actualisations et des ajouts en permanence, mais 
nombreuses sont celles qui restent a l'etat de XEP et ne sont pas implementees. La liste 
exhaustive des XEP publiees est disponible sur le site de Jabber, a l'adresse http://jabber.org/ 
jeps/ 

Jingle, la XEP de Jabber dediee a la TolP 

Originellement, Jabber ne se preoccupait que de messagerie instantanee. La TolP n'est 
traitee que comme une extension pour repondre a la demande des utilisateurs reclamant 
ce service. De ce fait, la gestion de la voix n'est pas decrite par le protocole XMPP, et il 
est parfaitement envisageable d'utiliser SIP pour offrir un service de telephonie conjoin- 
tement avec l'utilisation de Jabber. Certains clients logiciels s'y sont d'ailleurs essayes, 
comme OpenWengo. 

C'est done sous la forme d'une extension XEP que la TolP peut etre implementee sur la 
plate-forme Jabber. Publiee en octobre 2005 sous le nom de Jingle, elle est referencee par 
la documentation XEP-0166, etendue par la XEP-0167 pour les formats de donnees. 
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Jingle remplace 1' obsolete protocole TINS (Transport for Initiating and Negotiating 
Sessions), defini dans la XEP-01 11, qui n'a connu qu'une seule implementation, appelee 
Jabbin, peu couronnee de succes. Jingle a ete con^u de concert avec les equipes de deve- 
loppeurs de Google. 

On raconte que les travaux de Google et ceux de Jabber se sont croises lorsque les deve- 
loppeurs se sont apergus de la forte parente de leurs avancees en matiere de definition 
d'un protocole de session multimedia. Les documentations de Jabber ay ant ete rendues 
publiques, Google a propose d'unir les forces pour la conception de ce protocole. C'est 
ainsi que, en decembre 2005, une implementation de Jingle nommee libjingle a ete reali- 
see par Google et rendue disponible au public sous la forme d'une bibliotheque libre 
(accessible a l'adresse http://code.google.com/apis/talk/index.html). 

Plusieurs logiciels ont integre cette implementation, a commencer par Google Talk, le 
logiciel de messagerie de Google, que nous detaillons ulterieurement dans ce chapitre, 
mais egalement PSI et Kopete. 

Notons qu'avec Jingle, Jabber ne gere pas uniquement la voix, mais n'importe quel 
contenu binaire, y compris multimedia. Ainsi, Jingle devrait a terme permettre l'echange 
de videos (XEP-01 80). 



Utilisation 



Jabber n'est ni un client, ni un protocole mais plutot une plate-forme con^ue par 1' asso- 
ciation des RFC deflnissant le protocole XMPP et des ameliorations proposees dans les 
XEP. II a ete developpe par une communaute libre tres active et a ete implements par 
plusieurs logiciels clients et serveurs, parfois libres, parfois proprietaries. 

Cette section presente les serveurs et clients les plus courants et les possibilites d' extension 
de Jabber. 

Choix du serveur 

Le serveur est l'entite en charge de la gestion des comptes des utilisateurs. II fournit a ces 
derniers les services auxquels ils ont souscrit et assure notamment les fonctions de loca- 
lisation et de mise en relation des contacts. 

Les utilisateurs se connectent a leur serveur en utilisant l'un des clients logiciels que nous 
detaillons plus loin dans ce chapitre. II leur faut prealablement choisir un serveur. Ce 
choix n'est pas necessaire pour des logiciels tels que Skype, WLM et Yahoo!, car il est 
implicite et contraint. Jabber n'etant pas un modele proprietaire, il ne dispose pas de 
serveur predefini. Aucun serveur n'est affecte par defaut aux utilisateurs Jabber, et il est 
meme a leur charge d'en selectionner librement un, parmi tous ceux que la communaute 
Jabber laisse a leur disposition. 

Pratiquement, cette phase n'implique qu'un simple choix de serveur dans une liste 
proposee, qui doit etre ensuite valide au niveau du client. 
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JID (Jabber ID) 

Un utilisateur a pour identifiant un pseudonyme auquel est associe le nom du serveur 
Jabber qui le prend en charge. L' identifiant d'un utilisateur obeit done au format suivant : 

pseudonyme @ serveur J abber_choisi 

Cet identifiant est unique. Le choix d'un serveur Jabber se reflete ainsi dans son identi- 
fiant de connexion. Une fois le serveur Jabber specifie dans 1' identifiant de 1' utilisateur, 
ce dernier ne peut changer de serveur sans modifier son identifiant. C'est exactement 
comme pour un serveur de messagerie, qui est mentionne apres l'arobase d'une adresse 
e-mail. 

Pour choisir son serveur Jabber, on peut consulter la liste des serveurs publics et gratuits 
accessible sur le site de Jabber (http://www.jabber.org) a la section Servers. 

Voici quelques serveurs Jabber connus : 

• APINC (association pour la promotion de l'lnternet non commercial). Localise en 
France, ce serveur constitue un choix pertinent. II dispose des passerelles vers la 
plupart des reseaux des autres clients de messagerie (AIM, ICQ, MSN et Yahoo!) et 
permet d'utiliser un tres large choix de noms de domaines (parmi lesquels les 
domaines jabber.fr et im.apinc.org, dont l'APINC est proprietaire). II est possible 
d'utiliser son propre nom de domaine si Ton en possede un. La liste des domaines 
disponibles est referencee a la section « liste des domaines » du site de l'APINC, a 
1 ' adres se http://jabber. apinc. org. 

• Jabber.org. C'est le serveur le plus celebre, mais sa reputation en fait son principal 
defaut puisqu'il est particulierement sollicite, et done parfois ralenti. II centralise en 
outre enormement de comptes, ce qui est paradoxal, compte tenu de la philosophic 
distribute de Jabber, d'autant qu'il ne dispose pas de passerelles vers les autres clients 
de messagerie. Le serveur est gere par la JSF. Son domaine usuel ostjabber.org. 

• Amessage. Ce serveur localise en Allemagne est plutot bien maintenu et dispose de 
quelques transports. II offre des noms de domaines (notamment ames sage. info). Son 
principal attrait et de disposer d'un grand nombre de services, comme l'envoi de SMS, 
la gestion de blogs et la mise en place d'annuaires. Son site, en langue anglaise ou alle- 
mande uniquement, est disponible a 1' adresse http://web.amessage.info. 

Tous ces serveurs fonctionnent globalement tres bien, et il en existe beaucoup 
d'autres. II s'agit le plus souvent d'initiatives de benevoles voulant gerer un serveur 
communautaire. De fait, leur perennite n'est pas garantie, et leur stabilite peut parfois 
faire defaut, contrairement aux logiciels commerciaux grand public, qui disposent de 
moyens considerables. Si les pannes sont plus frequentes, l'equipe chargee de la gestion 
du serveur est en contrepartie plus accessible et disposee a apporter des evolutions aux 
services proposes. 

Le choix du serveur n'est pas anodin, a la fois pour les fonctionnalites et la qualite de 
service offertes, mais aussi parce que les administrateurs ont potentiellement la possibi- 
lity de lire les contenus des messages, la liste des contacts et le mot de passe associe au 
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compte, puisque l'ensemble de ces donnees transite par ces serveurs. En cas de doute, il 
est toujours possible de crypter ses messages afln d'eviter toute tentative frauduleuse 
d' interception. 

Monter son propre serveur Jabber avec ejabberd 

Jabber ne limitant pas les possibilites de choix du serveur, il est possible d' exploiter un 
serveur prive. Pour monter son propre serveur, un bon choix logiciel est fourni par 
ejabberd. 

Con^u en 2002, le serveur ejabberd a ete ecrit principalement en langage Erlang, defini 
par Ericsson pour les applications distributes, de type temps reel, avec resistance aux 
pannes et gestion optimisee des acces concurrents, d'ou son nom complet Erlang Jabber 
Daemon. 

Le serveur ejabberd fonctionne sous presque toutes les plates-formes (Windows, MacOS, 
Linux, BSD, Solaris, etc.) et est disponible en licence GNU GPL 2. 

L'atout principal d'ejabberd est sa robustesse, sa stabilite ayant ete testee avec des 
montees en charge de plusieurs milliers d'utilisateurs. II est notamment utilise sur le 
serveur de 1' APINC. 

ejabberd est telechargeable sur le site de l'editeur, a l'adresse http://ejabberd.jabber.ru. 

Choix du client 

La souplesse offerte dans le choix des serveurs permet en theorie de distribuer la charge 
tout en assurant l'interoperabilite entre serveurs. Mais choisir un serveur n'a que peu 
d'interet pour le client final. Ce dernier souhaite avant tout avoir le maximum de services 
disponibles sur une plate-forme unique a laquelle il se connecte. Ce n'est pas le cas avec 
Jabber, dont l'approche communautaire et non commerciale repose sur un modele artisa- 
nal, dependant de la bonne volonte d'individus qui ceuvrent a l'emergence de normes 
communes. 

La valeur ajoutee de Jabber s'exprime dans la tres large diversite des clients disponibles. 
Par defaut, l'utilisateur n'a aucun choix impose, contrairement a tous les autres logiciels 
de messagerie proprietaire. Le choix d'un serveur n'a pas d' incidence directe sur celui du 
client, sauf a verifier que ce dernier dispose des implementations permettant d'utiliser 
certaines fonctionnalites du serveur. 

Parmi les nombreux clients compatibles Jabber, citons notamment les suivants, tres 
connus et gratuits : 

• Psi, Gaim, Coccinella et Jabbin, pour Windows, Linux et Macintosh ; 

• Exodus, pour Windows ; 

• Gabber et Gossip, pour Linux. 
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Une liste tres large est disponible a la section Clients du site de Jabber. Une fois un client 
choisi, il est parfaitement envisageable d'evoluer sans contrainte vers un nouveau client, tout 
en conservant son identiflant de compte Jabber. 

Mieux encore, comme le protocole est libre, n'importe quel programmeur peut imple- 
menter son propre client et le redistribuer eventuellement ensuite. Les sources deviennent 
done particulierement riches. 

Configuration d'un client Jabber 

Nous allons detailler quelques elements de configuration du client Psi, qui valent aussi 
pour le client Gaim, au libelle des fonctions pres. 

Apres avoir telecharge et installe Psi sur le site de l'editeur (http://psi.affinix.com), le lance- 
ment du logiciel invite l'utilisateur a renseigner son nom, qui correspondant a l'identi- 
flant d'un compte, existant ou non. II s'agit du nom d'un profll, car Psi gere les proflls 
multiples et permet a plusieurs utilisateurs de se connecter en meme temps sur la meme 
interface. Le nom specifle est seulement utile pour l'utilisateur, qui peut ainsi discerner 
chacun des proflls qu'il a crees. 

Nous considerons que nous ne disposons pas encore d'un compte Jabber et que nous 
souhaitons en creer un. En selectionnant la case « Enregistrer un nouveau compte » puis 
en cliquant sur le bouton Ajouter, la fenetre d'inscription au serveur illustree a la 
figure 11.2 s'ouvre. 



Figure 11.2 

Inscription au serveur 



W- Psi: Enregistrer le compte 



Compte 

IdenMfiant Jabber (JID): 



guy_laurent@jabber. f r 



Ex&mpfe: juiiefte@capute£ com 



Mot de passe: 

Confirmation du mot de passe: 



Proxy 


| Aucun 


rll 


Editer... 





Avancees — 
~^\ Utiliser le chiffrage SSL (avec le serveur) 
~^\ Specifier manuellement le serveur et le port: 

Serveur: 



Port: 



P!zi I 



Fermer 



Inscription 
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L'utilisateur est invite a saisir un identifiant et un mot de passe associe. C'est ici que le 
choix du serveur Jabber est mentionne. Ce choix peut se faire en utilisant la liste des 
serveurs disponible sur le site de Jabber, mais mieux vaut utiliser un serveur reconnu, 
comme ceux que nous avons mentionnes precedemment, comme celui de l'APINC. 

Le site Web de l'APINC fournit la liste des domaines que le serveur met a disposition des 
utilisateurs, par exemple le domaine jabber.fr. L' identifiant Jabber (JID) a dans ce cas le 
format nom_d_utilisateur@jabber.fr. 

Un message d'erreur est renvoye si le nom d'utilisateur est deja utilise par un autre 
membre. Choisissons pour identifiant guyjaurent, et associons-y un mot de passe de 
notre choix, repete par securite a la ligne suivante. Ignorons les parametres de 
connexions particulieres, tels que les connexions par un serveur proxy ou les connexions 
differentes de celles s'effectuant sur le port par defaut (port 5222). 

En validant la procedure par le bouton Inscription, le logiciel client tente de se connecter 
au serveur Jabber de l'APINC afln d'y effectuer la creation du compte requis. Si le 
serveur est trouve et que 1' identifiant est disponible, un message annon^ant que 1' inscrip- 
tion au serveur s'est correctement deroulee s'afflche. Dans le cas contraire, un message 
d'erreur est retourne. 

La derniere etape correspond a l'enregistrement d'une carte virtuelle, ou VCard, rassem- 
blant l'ensemble des informations que Ton souhaite diffuser aux autres utilisateurs (voir 
figure 11.3). Optionnelle, cette etape peut etre renseignee ulterieurement ou partiellement 
selon les informations que Ton souhaite partager avec les autres utilisateurs. 



Figure 11.3 

Renseignement d'une VCard 



guy_la u re nt @ ja b be r . f r 



General Travail Adresse postale A propos de 



Norm cormplet 

Surnonn 

Date de naissance | 

Telephone 

Page web 

Courriel 



Pb I 



| Laurent Guy 


|Lo 


^Jabber 












I I 


Ouvrir... Vider 



Publier 



Recuperer 



Fernner 



L'enregistrement de cette flche personnelle (et, de maniere generale, de toutes les options 
du compte, incluant la liste des contacts), se fait directement au niveau du serveur. 
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De cette maniere, il devient possible d'acceder a son compte a partir de n'importe quelle 
autre station, simplement avec son identiflant et son mot de passe. 

Sur la figure 11.3, le bouton Recuperer permet d'importer localement l'ensemble des 
parametres enregistres au niveau du serveur. Au contraire, en cliquant sur le bouton 
Publier, 1' ensemble des informations est envoy e et sauvegarde sur le serveur. 

L' interface principale de Psi s'afflche alors, comme illustre a la figure 1 1.4. A ce stade, le 
client est generalement hors connexion. II lui faut modifier son statut pour se connecter 
au serveur. 



Figure 11.4 

Interface de Psi 




T>>) T C?En-ligne^ 



Presque simpliste, cette interface recele neanmoins quantite d' options et de parametres 
de configuration. Les quelques boutons par defaut permettent de specifier les categories 
de contacts que Ton souhaite voir s'afflcher. En bas de 1' interface, les deux boutons avec 
une fleche descendante sont en fait des menus deroulants. 

Le menu de droite permet de selectionner son statut de connexion. C'est celui a utiliser 
pour se connecter au reseau Jabber. On peut selectionner, par exemple, le mode En-Ligne 
ou le mode Invisible. Le menu de gauche, qui reprend le logo du logiciel Psi (du nom de 
la lettre grecque psi) est le menu principal du logiciel. II offre de nombreux parametres et 
options de configuration. 

Ce menu permet notamment de specifier toutes les informations de connexion. Pour 
acceder a la creation d'un compte (mais aussi a sa modification ou a sa suppression), 
comme on l'a fait precedemment, il faut selectionner « Configuration des comptes » puis 
cliquer sur le bouton Aj outer. 

La personnalisation de l'interface peut se faire via la fonction « Configurer les barres 
d'outils » ou v/a l'onglet Afflchage de la fonction Options. L'interface des options offre 
un grand nombre de possibilites de configuration, notamment des alertes ou des choix de 
sons sur evenements, ou encore la possibilite d'afflcher la traditionnelle barre de menus. 
Notons egalement la possibilite de rejoindre un groupe de discussion dont on connait 
l'adresse du serveur et le nom de la salle de discussion. 
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Services complementaires 

Des services complementaires peuvent etre proposes par le serveur a ses utilisateurs. II 
s'agit le plus souvent de passerelles vers les autres reseaux de messagerie, mais il peut 
tout aussi bien s'agir de services de blog ou de calendrier partages entre plusieurs utilisa- 
teurs. Ces fonctionnalites sont toutefois rarement prises en charge en totalite sur tous les 
serveurs. 

Pour connaitre la liste des fonctionnalites disponibles, il sufflt de se rendre sur le site Web 
du serveur choisi et rechercher la section listant les fonctionnalites prises en charge. Si le 
client et le serveur le supportent, il est aussi possible d'utiliser son client pour interroger 
son serveur sur ses fonctions. 

Apres une breve inscription au transport souhaite, le service devient exploitable. La liste 
des services disponibles est accessible en selectionnant « Gestion des services » dans le 
menu principal, en bas a gauche du logiciel. Nous verrons, plus loin, un exemple de 
transport pour l'ajout d'un contact appartenant a une messagerie non- Jabber. 

Ajouter des contacts WLM ou Yahoo! 

L'ajout d'un compte d'une messagerie proprietaire via un client Jabber presuppose que le 
serveur Jabber dispose d'une passerelle vers le reseau de messagerie du compte utilisa- 
teur a ajouter. Autrement dit, pour ajouter un contact WLM, un utilisateur doit utiliser un 
serveur integrant une passerelle WLM. C'est generalement clairement indique et mis en 
avant par le site du serveur utilise. 

Les contacts WLM comme Yahoo! ont la particularity d'utiliser les e-mails des utilisa- 
teurs comme identifiants. lis comportent done tous une arobase. II se trouve que Jabber 
exploite lui-meme 1' arobase pour indiquer un nom de domaine et le serveur Jabber en 
charge du compte. Pour eviter toute confusion, il faut done remplacer le symbole @ par 
celui du pourcentage (%) et faire preceder le tout d'un identifiant precisant la messagerie 
utilisee pour le compte. 

Par exemple, un contact ayant pour identifiant : 

mon_identifiant_sur_wlm @ hotmail. com 

doit etre ajoute par : 

mon_identifiant_sur_wlm%hotmail com@msn 

De plus en plus de clients effectuent automatiquement ces conversions a la place de 
l'utilisateur en reconnaissant le reseau de messagerie du contact qui est ajoute. C'est le 
cas notamment du client Psi. 

La liste de contacts d'un utilisateur n'est cependant pas importable d'un reseau concur- 
rent vers Jabber. Cela occasionne une lourde tache manuelle pour l'ajout de ces contacts. 
Mais cette contrainte vaut aussi pour les autres reseaux de messagerie. 

Generalement, seule la fonctionnalite de messagerie instantanee des protocoles concur- 
rents de Jabber est disponible en passant par une passerelle, ce qui exclut la gestion des 
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communications vocales et video, comme le transfert de fichiers ou toute autre fonction- 
nalite maison des autres editeurs. 

Jabber n'a pas vocation a remplacer les services concurrents, mais plutot a proposer une 
solution globale resolvant les problemes d'incompatibilite. Les methodes permettant 
d'acceder aux reseaux proprietaires concurrents ne sont qu'un moyen de valoriser cette 
plate-forme. 

Meme si, theoriquement, le modele peut etre etendu selon les besoins des utilisateurs et 
les perspectives d' evolution des developpeurs, dans la pratique, il est peu probable que 
cela depasse le service de base de la messagerie instantanee. La principale raison a cela 
est que les protocoles concurrents sont proprietaires et qu'ils sont susceptibles 
d'evoluer en permanence, rendant inoperables les passerelles et imposant aux deve- 
loppeurs de lourds travaux pour maintenir la compatibilite. Un utilisateur dont les 
contacts appartiennent tous au meme reseau n'a done pas forcement a passer par 
Jabber. 

Cooperation entre serveurs 

Lorsqu'un utilisateur se connecte par le biais d'un logiciel client compatible, une 
connexion au serveur Jabber choisi s'effectue. Elle actualise avant tout le statut de cet 
abonne en specifiant qu'il s'est connecte (sauf s'il a demande a rester masque). Cela 
permet aux autres utilisateurs d'en etre informes, mais aussi de recuperer le profil de 
l'utilisateur et l'ensemble des parametres qui y sont associes, notamment la liste de ses 
contacts. 

A ce stade, la presence dans le reseau de correspondants n'est pas forcement connue du 
serveur. Par contre, la liste des contacts recuperes permet d'interroger chacun des 
serveurs en charge des profils de ces contacts puisque l'identifiant de chacun d'eux porte 
la mention du serveur en charge du compte. Le serveur peut done contacter ces serveurs 
et, en retour, informer l'utilisateur connecte du statut de ses contacts. 

La figure 11.5 illustre la maniere dont les serveurs Jabber peuvent cooperer pour localiser 
les utilisateurs du reseau Jabber et offrir un service distribue et coherent. 

Performante, souple, puissante et evolutive, la plate-forme Jabber seduit de plus en plus 
les internautes, avec son modele fibre et ouvert qui s'oppose radicalement aux politiques 
des majors de l'industrie. Reste qu'au niveau des services proposes, Jabber souffre d'un 
certain retard. L' implementation de la video fait defaut, et les fonctionnalites sont encore 
globalement restreintes. 

II n'en reste pas moins que la definition de normes et l'appui d'importants acteurs jouent 
en sa faveur. Pour les communications de ses abonnes, Meetic, le numero un des sites de 
rencontres, utilise ainsi les protocoles Jabber. D' autres acteurs importants, comme la 
marque Orange de France Telecom, les utilisent dans les Messenger destines a leurs 
abonnes. Quant aux geants IBM et Sun, ils proposent egalement des logiciels exploitant 
Jabber. 



Jabber et Google Talk 



Chapitre 1 1 



[~ 



Liste des contacts 
de alain@dom1 : 

• beatrice@dom1 

• caroline@dom2 

• dominique@dom2 

• estelle@dom3 

i / 
i / 
i / 



Connexion 



\\\vy 
alain@dom1 



• beatrice@dom1 

• caroline@dom2 

• dominique@dom2 

• estelle@dom3 





caroline@dom2 




dominique@dom2 



-—►i 



estelle@dom3 



dom3 



Figure 11.5 

Le modele cooperatif des serveurs Jabber 

Plus encore, le nouveau service de messagerie instantanee Google Talk du celebre 
moteur de recherche Google implemente les protocoles Jabber et dispose meme d'une 
passerelle de communication pour se connecter au reseau Jabber. Les utilisateurs de 
Google Talk peuvent contacter les utilisateurs Jabber et vice versa. Google va encore plus 
loin en contribuant au developpement des technologies Jabber, en particulier dans le 
domaine du traitement de la voix sur IP. 



Google Talk 



Cree en 1998 par deux chercheurs en informatique, Sergey Brin et Larry Page, Google 
n'en flnit pas de tisser sa toile sur le reseau. La societe, dont le siege est a Mountain View, 
en Calif ornie, se fixe comme politique de realiser elle-meme la plupart de ses developpements 
et d'etre presente dans tous les domaines technologiques strategiques. 

Peu de rachats pour 1' acquisition de societes, done, mais des developpements tous 
azimuts. Plus incroyable encore, pour un acteur dit pure player (e'est-a-dire dont 
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l'activite est visible uniquement sur Internet, et dont les benefices se font majoritairement 
sur les revenus publicitaires), Google ne passe aucune publicite sur Google Talk. Autant 
dire que la societe est attendue au tournant et que les erreurs de parcours peuvent lui 
couter cher. 

L'un des derniers fers de lance de l'insatiable societe Google, comparee a une pieuvre 
pour la diversite de ses activites, concerne la telephonie et ses derives. A nouveau, la tele- 
phone se couple a l'inevitable messagerie instantanee, mais pas seulement. 

Une off re a trois volets 

Pour Google, le service de telephonie Google Talk n'est que le troisieme volet de son 
offre de communication pour les internautes, qui inclut aussi Google Mail, le courrier 
electronique, et Google Chat, la messagerie instantanee. 

Google Mail 

Google Mail (GMail), le webmail de Google, propose une interface sobre mais haute- 
ment fonctionnelle et particulierement rapide. Avec GMail, la societe demontre, s'il en 
etait besoin, qu'elle est un acteur avec qui compter, meme dans un domaine largement 
occupe par les champions Microsoft et Yahoo!. 

Pour preuve, la version Beta de la messagerie est restee, pendant presque trois ans, acces- 
sible uniquement a un panel d'utilisateurs tries sur le volet, qui pouvaient inviter d'autres 
internautes a se creer un compte. Plusieurs sites ont cependant ete crees pour faire don 
(ou commerce) de ces precieuses invitations, qui revetaient un parfum d'exclusivite et de 
privilege. La transmission virale s'est ensuite repandue a tres grande vitesse. 

L' innovation du service est reelle. Le webmail de Google compte parmi les plus rapides 
et puissants du marche. Reposant sur une interface sobre, il est programme en Ajax, le 
nouveau langage a base de controles JavaScript qui offre une tres large liberte d' action et 
de personnalisation. 

Gratuit et dote d'un espace de stockage de plusieurs gigaoctets, Google Mail fourmille 
d'innovations. Ses capacites de recherche et d' organisation de courriers electroniques 
sont remarquables d'efflcacite et de precision. II se complete de maniere naturelle par un 
simple lien avec l'outil de gestion d' agenda Google Calendar. 

Google Chat 

Toujours en version limitee, la messagerie instantanee Google Chat est discretement 
passee a la vitesse superieure en proposant un canal de communication par messagerie 
textuelle. Accessible a l'aide d'un navigateur Internet, le service est totalement integre a 
l'interface de Google Mail. 

Le carnet d'adresses de la messagerie electronique est communement partage par la liste 
de contacts de la messagerie instantanee. Par un simple clic sur l'interface du webmail, 
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les utilisateurs peuvent connaitre la disponibilite de leur contact et communiquer entre 
eux, en temps reel, par des messages textuels. 

Google Talk 

Troisieme volet de la communication initiee par Google, la ToIP a ete lancee le 9 aout 
2005. Dans Google Talk la conversation est fluide, stable, sans coupure ni retard perceptible 
et globalement d'excellente qualite. Le tout est par ailleurs peu gourmand en ressource. 

Comme Google Chat, Google Talk s'appuie sur le standard Jabber/XMPP et herite de 
tous ses avantages, a commencer par un reseau decentralise et une grande flexibilite du 
client de messagerie. II est ainsi possible d' exploiter les serveurs de Google pour ses 
communications en utilisant un client different de Google Talk. 

Rappelons que le protocole Jabber laisse tout loisir au developpement d' extensions 
annexes puisqu'il est ouvert. 

Utilisation 

Disponible sous toutes les plates-formes Windows recentes, le client Google Talk se tele- 
charge sur le site de Google et pese a peine quelques megaoctets. 

Apres une installation sommaire et 1' execution du logiciel, la conventionnelle fenetre 
d'authentification s'affiche. L'utilisateur est invite a y saisir son identifiant Google Mail 
(avec ou sans le nom de domaine gmail.com) et son mot de passe associe pour acceder a 
1' interface principale. 

Comme l'illustre la figure 11.6, celle-ci se distingue par sa sobriete. Tres peu coloree, 
elle est reduite au strict necessaire et ne propose que peu d' options. L' accent est mis sur 
1' aspect fonctionnel du logiciel. Sa simplicite sollicite faiblement les ressources systeme. 
II n'en dispose pas moins d'une vaste gamme d'outils permettant sa personnalisation, avec 
notamment la possibilite de choisir son avatar ou l'apparence des fenetres de discussion. 

R 9 ure11 - 6 Google Talk ^^^^^^^ M 

Fenetre principale de Google Talk ,_, , . .... 

F r 6 Pararnetres I Aide 
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> Rechercher un contact dans la liste 



Guy C 

En conference, de retourdans une heure 
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Ajouter des contacts 

Les utilisateurs du webmail de Google apprecieront de ne pas avoir a entrer dans 
Google Talk la liste de leurs contacts, car celle-ci est automatiquement importee de 
Google Mail vers Google Talk. La liste est directement disponible dans la partie 
centrale du logiciel. 

Contrairement a d'autres logiciels, le nombre de contacts est illimite. Ces contacts ne 
sont pas encore joignables pour autant, et il est necessaire d'envoyer une invitation a 
chacun d'eux avant de pouvoir etre mis en relation. Pour cela, un double-clic sur le nom 
du contact suffit. Le contact re£oit alors une invitation lui demandant s'il accepte d'affi- 
cher son statut a son correspondant et s'il souhaite lui aussi ajouter ce dernier a la liste de 
contacts (voir figure 11.7). 



Figure 11.7 

Ajouter un contact 



*\ Search all contacts 



O laurentoo@grnail.corn wants to add you 
as a friend. Add as a friend? 



[ ^s ] [ no ] 



Lancer une communication 

En double-cliquant sur le nom d'un contact de sa liste, une fenetre de conversation est 
lancee. Comme l'illustre la figure 1 1.8, celle-ci est relativement rudimentaire, en tout cas 
tres loin des sophistications disponibles sur Skype, WLM ou Yahoo. 



Figure 11.8 

Fenetre de communication de la 
messagerie instantanee 




\. 



Guy: Je suis au Bresil pour une conference. 
Je reviens Lundi prochain. 

Laurent: Sur quoi porte la conference ? 



Guy: Sur les reseaux IP de domain. 



_ 



Comme on le voit, l'interface est epuree et ne comporte que les quatre boutons de 
controle suivants : 

• Appeler. Permet de lancer une communication telephonique avec le correspondant 
dont la fenetre est ouverte. Seules les communications en IP sont possibles. Le service 
actuel utilise Jingle (XEP-0166), via 1' implementation protocolaire libjingle que 
Google a realisee et rendue publique. L' integration avec le protocole SIP est prevue 
dans une prochaine version. 
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• Fichiers. Permet d' envoy er un document, quel que soit son format (texte, audio, video 
ou autre), a un correspondant. L'originalite de cette fonction repose sur la possibilite 
de visualiser un aper^u des images transmises. 

• E-mail. Permet d'ouvrir son navigateur par defaut sur la page de Google Mail et 
d' envoy er un e-mail a son correspondant. 

• Voicemail. Permet de laisser un message audio sur la messagerie de son correspondant 
(que ce dernier soit en ligne ou non). Les messages laisses sont ensuite accessibles sur 
l'interface principale grace a une icone disposee au bas de l'interface, a cote du 
nombre d' e-mails, et indiquant le nombre de messages stockes sur son repondeur (voir 
figure 11.6). 

Les messages vocaux sont egalement disponibles directement dans l'interface Web de 
son compte Google Mail. II est possible de telecharger ces messages sous forme de fichiers 
audio au format MP3 ou de les ecouter a partir du navigateur (si ce dernier dispose du 
plug-in Flash). 

Ces fonctionnalites sont relativement peu nombreuses en comparaison de celles des 
concurrents. Une conversation avec la messagerie instantanee ne peut faire intervenir que 
deux personnes au maximum. La telephonie se restreint au monde IP, et la video n'est 
pas disponible, meme entre utilisateurs du reseau IP. En depit de ces limitations, le 
programme GMail progresse, tout en fournissant un service de qualite, que ce soit en 
termes de disponibilite, de fiabilite ou de performance. 

Integration avec le service Google Mail 

Le service de Google est con^u pour unifier les communications, quels que soient les 
canaux utilises. Si un utilisateur n'a pas installe le client Google Talk, le simple fait qu'il 
se connecte sur sa messagerie webmail le rend neanmoins potentiellement disponible 
pour n'importe quel utilisateur de sa liste de contacts. 

En fait, le service GMail agit pour 1' utilisateur comme un client Jabber, au meme titre 
que le logiciel Google Talk, a cette difference pres que ses fonctionnalites sont degra- 
dees par rapport au logiciel Google Talk, lequel s'appuie sur une installation et l'acces 
a des ressources systeme dont le navigateur ne dispose pas. Ces fonctions sont toute- 
fois accessibles avec un simple navigateur, quel que soit le systeme d' exploitation 
utilise. 

En plus de disposer de son service de messagerie standard, 1' utilisateur est automatique- 
ment enregistre comme un client Jabber lorsqu'il accede a GMail. L'affichage de 
l'ensemble de ses correspondants se fait par le biais de la section Contacts. Cette derniere 
liste exhaustivement l'ensemble des contacts et permet de configurer, dans la section 
« Contacts rapides » illustree a la figure 11.9, les contacts qui seront disponibles en 
permanence sur l'interface. 
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En regard du nom de chaque contact, la disponibilite et l'etat sont indiques. L'icone qui 
precede le nom de l'utilisateur peut varier selon l'etat. Par exemple, si un correspondant 
est en train de converser par messagerie instantanee, son icone symbolise une info-bulle 
pour indiquer qu'une communication est en cours. 



Figure 11.9 

Etat des contacts et 
actions disponibles 



Contacts 

▼ Contacts rapides 



Rechercher, ajouter, inviter 



• Guy 

En conference 



Qlaurentoo 
Disponible 
Ajouter un 
contact 



Af f icher tout 







M Message 


£> Chatter 








laurentoo 

Disponible 
laurentoo@qmail.com 

Informations sur le contact 




Conversations recentes 
Afficher dans Contacts rapides r t 


Auto £ 



Pour selectionner un contact, il sufflt de pointer la souris sur l'identifiant correspondant. 
Une fenetre informative s'afflche alors et presente deux boutons d' action. Le premier 
permet d' envoy er un courrier electronique, et le second d'initier un dialogue par messa- 
gerie instantanee avec le contact. Si ce dernier n'est pas connecte, le bouton est grise, et 
done inaccessible. S'il est connecte (que ce soit au travers du logiciel Google Talk, d'un 
client alternatif ou de son webmail), le bouton est disponible, et un simple clic lance la 
fenetre de dialogue illustree a la figure 1 1.10. 



Figure 11.10 

Fenetre de la messagerie 
instantanee avec le webmail 



Envoye dirnanche a 02:16 
Guy: Je viens de t'envoyer un 
mail. 

Est-ce que tu I'as regu ? 
moi: Oui ! 

Je suis justernent en train de 
le lire. 



* 



H 



Options 



Fenetre externe^ 
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Cette fenetre de dialogue est persistante. Elle reste afflchee meme si Ton se deplace dans 
les differentes sections de son webmail, afin d'y lire ou ecrire ses e-mails. Cette meme 
interface Web permet d'inviter parallelement plusieurs contacts a discuter. Seuls les 
messages textuels sont possibles via le webmail, a 1' exclusion done des fonctions de tele- 
phonic 

II est possible pour un utilisateur de selectionner un statut parmi tous ceux qu'il a person- 
nalises dans Google Talk (ces statuts sont sauvegardes au niveau du serveur, et non pas en 
local sur le poste de 1' utilisateur) ou bien d'en saisir un nouveau. 

Reciproquement, tous les correspondants peuvent initier une conversation avec un utili- 
sateur de GMail. Dans ce cas, une alerte est remontee a ce dernier, lui precisant qui 
souhaite le contacter et lui demandant s'il souhaite accepter la conversation (voir 
figure 11.11). 



Gwail 

byCoogfc 

Nouveau message 



Borte de reception 

Suivi if 

Tous les chats Q 

Messages envoyes 

Brouillons 

Tous les messages 

Spam 

Comeille 

Contacts 

▼ Contacts rapides 
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Rechercher, ajouter, inviter 



1 Guy 
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laurentoo@gmail.com 
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D'accord ? 
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Figure 11.11 

Invitation a partir de GMail 



Pratique de la TolP 



Parte II 



Gestion des connexions multiples 

Lorsqu'un utilisateur est connecte simultanement de differentes manieres, il regoit son 
premier message sur l'ensemble des supports auxquels il est connecte. Des qu'il repond 
par le biais de Tun de ces supports, la conversation se poursuit uniquement sur ce canal. 

Par exemple, si l'utilisateur Guy est connecte par le client Google Talk en meme temps 
qu'il consulte ses e-mails sur Google Mail, un message instantane de l'utilisateur 
Laurent lui parvient simultanement sur Google Talk et sur son webmail. Si Guy repond 
ensuite a partir de son webmail, les prochains messages de Laurent lui parviennent sur 
son webmail uniquement. 

Si, pendant la conversation, Guy decide de passer sur son client Google Talk, sa conver- 
sation bascule sur ce nouveau support, et les prochains messages de Laurent sont afflches 
sur le client Google Talk uniquement. 

Google fournit ainsi de multiples manieres de se connecter a son reseau de messagerie. 
Ne serait-ce qu'en consultant leur messagerie Web, les utilisateurs restent joignables, a 
leur travail comme a leur domicile, sans jamais avoir besoin de se deconnecter. 

Google Talk avec un logiciel alternatif 

Comme le protocole Jabber l'autorise, un meme utilisateur peut etre connecte plusieurs 
fois simultanement. On en a vu une illustration avec un utilisateur connecte au reseau 
Jabber a la fois par Google Talk et Google Mail. Celui-ci pourrait tout aussi bien utiliser 
un autre client que celui propose par defaut. 

La societe Google encourage du reste les programmeurs a creer de nouvelles applications 
clientes. La seule condition est que ce client respecte les specifications du protocole 
ouvert Jabber. 

Dans un tel cas, il suffit alors de configurer le logiciel avec les parametres recapitules au 
tableau 11.3. 

Tableau 1 1 .3 - Configuration d'un logiciel alternatif a Google Talk 



Parametre 


Valeur 


Serveur d'authentification 


talk.google.com (sur le port: 5222) 


Norn d'utilisateur 


login_d'utilisateur_gmail 


Mot de passe 


mot_de_passe 



Les codecs suivants sont pris en charge pour les communications audio G.711 (PCM loi 
A et PCM loi mu), G.723, iLBC et Speex. Cette liste est restreinte, mais satisfaisante 
pour la majorite des utilisateurs. 

L'authentiflcation aux serveurs de messagerie de Google doit reposer sur le protocole 
SASL (Simple Authentication and Security Layer). Le transport des flux s'effectue de 
maniere chiffree par le protocole TLS (Transport Layer Security). 
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L'avantage des clients alternatifs est que, en plus de proposer des services complementai- 
res a ceux fournis par Google Talk, ils sont utilisables dans la majorite des plates-formes, 
alors que Google Talk n'est disponible que sous Windows. 



Conclusion 



L' unification des reseaux de messagerie et de telephonie IP est un enjeu important, vive- 
ment souhaitee par les utilisateurs pour elargir leur cercle de contacts. Redoutee par les 
majors qui dominent le marche et risqueraient de perdre les utilisateurs habitues, cette 
unification pourra se faire selon deux axes : soit en implementant les protocoles de 
chaque logiciel (bien souvent par des partenariats entre les acteurs), soit sur la base d'un 
protocole utilise par tous. 

Pour se faire connaitre du grand public, la plate-forme Jabber n'etant pas lucrative, n'a 
certes pas la puissance commerciale des logiciels concurrents. De plus, elle ne centre pas 
non plus ses developpements autour de la telephonie, mais vise principalement la messa- 
gerie instantanee. La telephonie n'est que 1' indispensable extension de la plate-forme. 
Toutefois, Jabber a le merite de proposer une approche libre, ouverte et normalisee, ce 
qui permet de poser de solides bases aux nouveaux acteurs et aux developpements des 
particuliers, tout en ouvrant la voie a une unification des reseaux de messagerie et de tele- 
phonie. 

Mail, messagerie instantanee et telephonie : l'integration des trois facettes de l'offre 
Google dans une interface simple et fonctionnelle semble naturelle, meme si le logiciel 
reste encore tres limite en termes de fonctionnalites. 

Si l'offre s'enrichit progressivement, elle reste loin derriere celles des leaders Microsoft 
et Yahoo!. Le service se cantonne a la telephonie purement IP, et il n'est pas encore possible 
d'appeler ni d'etre appele avec des telephones standards. La personnalisation du logiciel 
reste par ailleurs pauvre. 

Le logiciel est cependant encore jeune et ne cesse d'evoluer. S'il presente des limitations 
certaines, il n'en reste pas moins un modele de stabilite et de simplicite d' utilisation. Le 
protocole utilise a la capacite de seduire des utilisateurs des autres reseaux de messagerie, 
qui peuvent conserver leur liste de contacts en passant a la technologie Jabber. 

Lorsque les habitudes seront prises chez les utilisateurs, la montee en service sera inevi- 
table tant la societe dispose d'une force de frappe considerable. De fait, la veritable ques- 
tion n'est peut-etre pas de savoir quelle societe detient le plus de clients ou possede le 
logiciel le plus performant, mais plutot quel acteur rassemblera tous les autres. De ce 
point de vue, Google est indeniablement sur les rangs. 
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Asterisk 



Les grandes entreprises sont dotees de centraux telephoniques, appeles autocommutateurs, 
PABX (Private Automatic Branch eXchange) ou plus simplement PBX. 

Un PBX est une entite logique, presque toujours geree par un equipement materiel physi- 
que dont la fonction est au moins triple : router les appels au sein d'un reseau prive, inter- 
connecter les reseaux et gerer les services de telephonic 

Ce chapitre se penche sur un PBX d'un genre nouveau, le logiciel Asterisk, qui remplit 
les memes fonctions qu'un PBX professionnel de haut niveau. Aucun equipement speci- 
fique n'est necessaire, et il suffit d' installer le logiciel sur un ordinateur, librement et 
gratuitement. Ce type de logiciel est appele IPBX, ou PBX-IP. 

Grace a son architecture modulaire, a sa facilite de mise en oeuvre rapide et a son fonc- 
tionnement simplifie, Asterisk peut meme etre installe par des particuliers, qui peuvent 
ainsi exploiter les ressources gigantesques dont il dispose. 

Introduction aux PBX 

Seul element du reseau a connaitre la localisation de chaque terminal telephonique, le 
PBX a pour fonction principale le routage. Les terminaux sont des entites elementaires, 
ce qui reduit leur cout unitaire et permet leur gestion centralisee. 

Lorsqu'on ajoute un terminal telephonique au sein d'une entreprise, il n'est pas neces- 
saire de modifier les autres terminaux pour les en informer. C'est le PBX qui centralise 
l'intelligence du reseau et effectue les taches de connectivity, de mise en relation des 
interlocuteurs et de gestion des communications locales au reseau. II assure en outre la 
liaison avec le reseau telephonique commute global. Autrement dit, le PBX fait office de 
passerelle telephonique pour les communications locales (d'un point de vue logique et 
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non physique), mais aussi pour celles entre les utilisateurs du reseau local et les utilisateurs 
relies au reseau telephonique traditionnel. 

De cette fa^on, les communications locales ne sont plus facturees par l'operateur de tele- 
phonie, puisqu'elles n'arrivent pas jusqu'a lui. Gerees en interne par le PBX, elles 
deviennent gratuites. De plus, les services mis en place sur le PBX (annuaire, messagerie, 
etc.) sont independants de l'operateur telephonique. 

Un autre avantage des PBX est que l'entreprise n'a plus besoin d' avoir autant de lignes 
telephoniques exterieures qu'elle dispose de lignes en interne. Dans la mesure ou il est 
peu probable que tous les telephones d'une entreprise soient utilises en meme temps, il 
est possible de limiter le nombre de lignes exterieures a ouvrir en majorant statistique- 
ment l'usage qui est fait des telephones. Ainsi, toutes les lignes internes peuvent 
communiquer, a condition qu'elles ne le fassent pas toutes en meme temps. C'est ce 
qu'illustre la figure 12.1. 

Dans la pratique, les utilisateurs ne per^oivent pas cette limitation, a de rares exceptions 
pres, comme lors d'incendies, au cours desquels certains appels peuvent ne pas aboutir 
en raison de l'affluence des communications. C'est la raison pour laquelle on recom- 
mande de reduire au minimum les appels dans ces circonstances particulieres. 
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Figure 12.1 

PBX pour la gestion des appels 



Les PBX peuvent servir a heberger differents services telephoniques, comme un serveur 
vocal, un repondeur personnalise, la redirection d' appels ou encore la tenue de journaux 
d' appels. Nous donnons un peu plus loin une liste de quelques services parmi les plus 
connus. 
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Les PBX assument enfin la fonction d' interconnexion de reseaux de nature differente. En 
effet, il ne sufflt pas qu'une entreprise souhaitant passer a la ToIP s'equipe de terminaux 
telephoniques IP. Pour permettre aux utilisateurs de joindre le reseau telephonique RTC, 
une passerelle doit etre hebergee au sein du PBX. Enjeu majeur, c'est 1' interconnexion 
entre reseaux qui permet de federer les reseaux et d'offrir une plate-forme de services 
transparente pour l'utilisateur, lui permettant d'acceder aux memes services, quel que 
soit le reseau qu'il utilise. 

Presentation d'Asterisk 

Dans la plupart des langages informatiques, l'asterisque (dont le symbole est *) est utilise 
comme caractere generique (en anglais wildcard), pour remplacer n'importe quel autre 
caractere ou ensemble de caracteres. II s'agit en quelque sorte d'un joker, la carte ou 
valeur qui remplace toutes les autres. C'est de ce concept de genericite, evoquant a la fois 
la souplesse, l'adaptabilite et la puissance, que tire son nom le logiciel Asterisk. 

Asterisk est un PBX-IP, ou IP PBX ou encore IPBX. Complet et performant, il offre une 
plate-forme personnalisable et modulable pour la mise en oeuvre de services de telepho- 
nic II garantit une tres large interconnexion avec plusieurs serveurs PBX, mais aussi 
avec des reseaux de telephonie non-IP. 

Developpe en 2001 par Mark Spencer, de la societe americaine Digium, il continue 
d'etre fortement soutenu par cette derniere. En France, c'est la societe Eikonex qui assure 
le catalogue commercial de Digium et propose des formations sur le logiciel, ainsi que le 
developpement d' applications pour des centres d'appels. Eikonex commercialise aussi 
des cartes servant d' interfaces entre differents reseaux et egalement des ordinateurs 
complets, preinstalles et equipes de l'ensemble des equipements optionnels dont on 
souhaite disposer. 

Asterisk etant un logiciel libre d' utilisation, ses sources sont telechargeables sous licence 
GNU GPL (General Public License). Cela permet a une importante communaute de 
contribuer a son developpement. Des forums libres et actifs enrichissent, testent, mettent 
a jour et ameliorent en permanence le logiciel. Bien qu'initialement con^u pour fonction- 
ner sous Linux, il est aujourd'hui multiplate-forme et s'installe aussi bien sur OpenBSD 
que FreeBSD, Sun Solaris, MacOS X ou Windows. 

L' enjeu d'une offre telle qu' Asterisk est colossal. Pour peu que Ton dispose des connais- 
sances requises, il devient possible de remplacer une lourde et tres onereuse mise en 
oeuvre d'un equipement PBX par un simple ordinateur equipe du logiciel gratuit, even- 
tuellement muni de cartes d' interfaces pour 1' interconnexion avec differents types de 
reseaux non-IP. Le logiciel se pose en rival viable et robuste dans un marche domine par 
les geants Alcatel, Nortel, Cisco, 3Com, Avaya ou Siemens, pour ne citer que quelques- 
uns des equipementiers les plus connus. 

Allechees par une economie d'environ 50 % par rapport aux solutions hardware classiques, 
les entreprises multiplient 1' adoption de ce type de solution. 
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Fonctionnalites 



Asterisk propose toutes les fonctionnalites d'un standard telephonique de niveau profes- 
sional, des plus elementaires aux plus complexes. Non seulement, il permet de gerer le 
routage des appels au sein du reseau, mais en plus il supporte une large gamme de servi- 
ces, notamment les suivants (pour la liste exhaustive, voir le site de l'editeur, a l'adresse 

http://www.asterisk.org) : 

• Authentiflcation des utilisateurs appelants. 

• Serveur vocal, ou standard d'accueil telephonique automatise, aussi appele IVR (Inte- 
ractive Voice Response). Cette fonction permet de demander a 1' appelant le service 
qu'il souhaite utiliser et d'effectuer le routage correspondant. 

Numerotation abregee pour definir des raccourcis. 

Transfert d'appel. 

Filtrage des appels. 

Messagerie vocale (repondeur automatique). 

Notification et ecoute par e-mail des messages laisses sur son repondeur (voicemail). 

Gestion des conferences. 

Double appel. 

Mise en attente. 

Journalisation des appels. 

Facturation detaillee. 

Enregistrement des appels. 

Le logiciel peut etre utilise comme une passerelle TolP heterogene. Par exemple, des 
utilisateurs utilisant differents protocoles de signalisation, comme H.323 ou SIP, peuvent 
etre mis en relation. C'est le logiciel qui se charge d'effectuer les conversions de signali- 
sation. De la meme maniere, il peut servir de passerelle pour joindre des correspondants 
dans le reseau telephonique RTC. Enfin, le logiciel est modulable et extensible au moyen 
de scripts et de modules implementes en langage C ou Perl. 



Compatibility 



Les supports protocolaires d' Asterisk sont tres larges. La signalisation sur IP est pleine- 
ment supportee avec les protocoles standardises les plus courants, notamment H.323, SIP 
et MGCP, mais aussi avec les protocoles IAX (Inter Asterisk eXchange), con^u dans le 
cadre du projet Asterisk, et SCCP (Cisco Skinny), con^u par Cisco. L'interoperabilite est 
egalement assuree vers la telephonie standard RTC (support pour E&M, E&M Wink, 
FXS, FXO, GR-303, Loopstart, Groundstart, Kewlstart, MF and DTMF, Robbed-bit 
Signaling (RBS) et MFC-R2), ainsi que vers la telephonie RNIS (support pour 4ESS, 
BRI (ISDN4Linux), DMS100, EuroISDN, Lucent 5E, National ISDN2 et NFAS). 

Par ailleurs, le logiciel supporte notamment les codecs audio suivants : G.711 (compati- 
ble avec la loi A et la loi ?), ADPCM, G.723.1, G.726, G.729 (soumis a une licence de la 
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societe Digium), GSM, iLBC, Linear, LPC-10 et Speex. Au niveau video, le support des 
codecs de reference H.263 et H.263+ est aussi fourni. Ce support des codecs les plus 
reputes offre une large palette de possibilites et couvre l'essentiel des besoins. 



Cible et usage 



La premiere vocation d' Asterisk est de remplacer les PBX d'entreprise, tres couteux, et 
dont les configurations different d'un equipement a l'autre. L'objectif est de proposer un 
logiciel capable de rivaliser avec ces equipements professionnels, a commencer par le 
support des fonctionnalites de localisation et de mise en relation des utilisateurs. 

S'il est naturel de concevoir la presence d'un central telephonique dans un cadre profes- 
sionnel, l'exploitation d'une telle puissance fonctionnelle peut-elle s'averer judicieuse 
dans un cadre domestique ? Dans un cadre prive, qui souhaiterait disposer d'un meca- 
nisme de standard automatique ? Qui souhaiterait demander a 1' appelant de saisir une 
touche correspondant au membre de la famille qu'il cherche a joindre ? 

Un PBX parait a priori trop puissant pour la maison, voire incongru. En realite, un PBX 
est bien plus que cela, et certaines de ses fonctionnalites etonnantes et souvent meconnues 
sont parfaitement adaptees aux besoins des particuliers. 

Reduire les couts en appelant de I'exterieur au tarif domestique 

De nombreux FAI proposent desormais la telephonie gratuite illimitee vers l'etranger. 
L'abonne, s'il est chez lui, n'a done pas a payer les appels longue distance et longue duree 
vers les destinations proposees. En revanche, il est facture tres cher pour les memes appels 
des s'il se trouve en dehors de chez lui, par exemple s'il appelle a partir de son telephone 
portable. Une solution bon marche a ce probleme consiste a utiliser Asterisk comme relais. 

Le principe du relais est simple. L'abonne dispose d'un serveur Asterisk correctement 
configure chez lui. Lorsqu'il est en deplacement, il appelle le serveur Asterisk. Celui-ci 
lance automatiquement un processus d'authentiflcation (par exemple en demandant a 
1' appelant de saisir un code d'acces ou en n'acceptant les appels que si le numero de tele- 
phone de 1' appelant est visible et connu du systeme). Au terme de l'authentiflcation, le 
serveur demande a l'appelant de saisir le numero d'appel de la personne qu'il veut join- 
dre et le compose automatiquement. II agit des lors comme un relais pour mettre en 
relation l'appelant et la personne que ce dernier souhaite joindre. 

Dans les conditions que Ton a mentionnees, l'appel compose par le serveur Asterisk vers 
la destination souhaitee est gratuit. En effet, le serveur etant situe chez l'appelant et relie 
a la ligne du fournisseur d'acces, il beneflcie des tarif s proposes par ce dernier. Au total, 
seul l'appel vers le serveur Asterisk est facture. 

Les etapes que nous avons mentionnees ne sont pas si contraignantes qu'elles peuvent 
paraitre a premiere vue. La meme demarche est exploitee par les operateurs de telephonie 
dits alternatifs, qui vendent des cartes prepay ees « a gratter » : en telephonant au numero 
indique, on s'identifle avec le code gratte avant d'appeler son correspondant. 
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1. 

2. 



La seule reelle contrainte est que le serveur Asterisk doit gerer deux appels en parallele : 
celui qu'il regoit de 1' appelant et celui qu'il emet pour le compte de ce dernier vers le 
destinataire. Cela implique de disposer de deux lignes telephoniques distinctes. Nous 
verrons que plusieurs operateurs proposent a moindre cout des lignes telephoniques IP 
associees a un meme numero de telephone. 

Pour aller plus loin dans cet exemple, on peut optimiser encore le fonctionnement decrit 
precedemment grace a la procedure dite de call-back. Dans ce scenario, l'appel initial est 
inverse, c'est-a-dire remplace par un appel initie par le serveur Asterisk : 

L' appelant appelle son serveur. 

Contrairement au cas precedent, ce dernier ne repond pas automatiquement a l'appel, 
mais repere le numero de 1' appelant et attend que ce dernier raccroche. Si ce numero 
est reconnu comme etant habilite a utiliser le service de call-back, le serveur Asterisk 
lance la procedure de call-back en initiant un appel vers 1' appelant. 

3. Une fois en contact avec 1' appelant, le serveur 1' invite a saisir ses commandes et a 
indiquer le numero de la personne a contacter. 

4. Le serveur Asterisk appelle le correspondant. 

La encore, deux lignes telephoniques sont necessaires pour faire fonctionner le service. 
Si Ton suppose que ces lignes sont forfaitaires, un cout mensuel, parfois inclus dans 
l'abonnement Internet, permettant d'appeler vers plusieurs destinations, l'appel est 
gratuit. Le call-back permet ainsi de beneficier de tarifs generalement avantageux. 

La figure 12.2 illustre la procedure de call-back. 



Etape 3 : 

/'appelant indique au 

serveur Asterisk le 

numero de la personne 

qu'il souhaite contacter 




Appelant 



Serveur 
Asterisk 



t/S^e, 



'■S5=££Ss* 



Appele 



Figure 12.2 

Procedure de call-back 



Asterisk 



Chapitre 12 

Assurer le nomadisme des utilisateurs 

Plusieurs services permettent de disposer d'un numero de telephone IP. Par exemple, 
1' option Skypeln de Skype fournit un numero geographique aux utilisateurs. Etant au 
format international, ce numero est utilisable depuis n'importe quelle ligne telephonique. 
L'utilisateur est de la sorte joignable quel que soit l'endroit ou il se trouve, pour peu qu'il 
dispose d'une connexion a Internet. 

Avec Asterisk, si un utilisateur voyage a l'etranger, il lui suffit de configurer son serveur 
(relie a sa ligne telephonique habituelle) pour demander une redirection des appels 
entrants vers un poste IP speciflque. Des qu'un appelant souhaite joindre cet utilisateur, il 
lui suffit de composer son numero de telephone pour que l'appel aboutisse au serveur 
Asterisk, lequel n'a plus qu'a activer la regie lui permettant de relay er l'appel vers le 
poste IP. 

Le meme service de nomadisme est disponible avec un telephone portable en activant 
1' option d' appels internationaux, si ce n'est que c'est l'appele qui est generalement 
facture pour la redirection d'appel de son pays d'origine vers le pays ou il se trouve. 

Ameliorer les services telephoniques 

Avec le serveur Asterisk, tous les services telephoniques usuels sont disponibles. Si 
certains d'entre eux sont plutot reserves a des usages professionnels, d'autres sont desti- 
nes au grand public. II est notamment possible, et gratuit, de disposer d'une numerotation 
abregee, d'interroger sa messagerie a distance, de recevoir des messages telephoniques 
sur sa messagerie electronique en format audio, d' avoir le detail complet des communi- 
cations passees, ou encore, sous reserve de disposer de 1' accord des participants, d'enre- 
gistrer des conversations, de lancer des conferences audio, etc. 



Installation de base 

En exploitant un ensemble de flchiers restreint, le PBX Asterisk offre une gamme de 
possibilites de configuration extremement large, repondant aux besoins les plus divers et 
permettant une personnalisation tres evoluee. 

Au premier abord, cette richesse d' exploitation et ce haut niveau de personnalisation 
et d' optimisation peuvent sembler rebutants pour les debutants. Plus encore, si la 
documentation d' Asterisk est globalement assez riche, elle est surtout disponible en 
langue anglaise. Cela vaut aussi pour les nombreux forums de discussion et d'aide 
dedies. 

L' ambition de cette section est de fournir une approche sufflsamment simple pour 
initier le lecteur aux concepts fondamentaux d' Asterisk et lui permettre de disposer 
en un temps record d'une premiere version elementaire, mais fonctionnelle, du 
serveur. 
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Sans pretendre a l'exhaustivite, puisqu'un livre entier serait necessaire pour exposer en 
detail toutes les possibilites et options disponibles, nous nous contenterons d'une approche 
synthetique de ces concepts nourrie de nombreux exemples. 

Nous commencerons par installer et executer le serveur avec une configuration par 
defaut. A ce stade, le serveur sera fonctionnel sans etre exploitable. A partir de cet envi- 
ronnement, stable et propre, et auquel il sera possible de revenir ulterieurement en cas de 
probleme, nous passerons a l'etape de configuration des flchiers, avant de nous pencher 
sur la mise en place de quelques services de base. Nous evoquerons ensuite des techni- 
ques d' optimisation de la configuration. Nous terminerons enfin par la presentation de 
fonctionnalites plus evoluees et fournirons des pistes pour poursuivre 1' etude du logiciel 
de differentes manieres. 



Mise en ceuvre de la plate-forme 

Au lieu de se lancer dans la configuration du logiciel, nous allons d'abord utiliser une 
configuration elementaire preinstallee dont nous detaillerons le fonctionnement avant 
de le personnaliser selon nos besoins. De cette maniere, nous limiterons les risques de 
mauvaises manipulations de flchiers et les fonctionnements inattendus. Les modifica- 
tions et l'enrichissement des parametres seront effectues de maniere progressive sur une 
base fonctionnelle. 

L' architecture d' Asterisk est modulaire. Autour du serveur, qui constitue son cceur et la 
seule brique indispensable, viennent se greffer plusieurs composants additionnels qui 
enrichissent ses fonctionnalites. II est done possible de n'installer que les elements dont 
nous avons besoin, en choisissant certains modules plutot que d'autres et en laissant la 
possibilite d'en aj outer ensuite, voire d'en concevoir soi-meme. 

Rien n'etant impose, nous pouvons determiner presque a la carte les complements a 
apporter. Par exemple, nous choisirons d' installer ou non un logiciel de synthese vocale 
en fran^ais, des pilotes supplementaires pour la gestion de composants hardware, un 
logiciel de facturation, etc. 

Les sections qui suivent presentent quelques composants classiques, dont nous 
detaillerons les implementations et exemples sous une plate-forme Linux. 

Se connecter au reseau telephonique traditionnel 

En TolP pure, le logiciel Asterisk est d'emblee fonctionnel, si bien qu'aucun composant 
supplementary n'est necessaire. Cependant, le reseau telephonique traditionnel utilisant 
une commutation par circuits, et non par paquets comme dans la telephonie IP, il est 
necessaire de s'equiper d'une interface permettant d'effectuer la conversion des signaux 
d'un flux IP en un flux RTC et reciproquement. 

Ces interfaces sont disponibles facilement dans le commerce, generalement sous 
forme de cartes PCI, a installer sur son PC, ou de boitiers, a connecter en USB. 
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lis offrent plusieurs branchements pour disposer de plusieurs lignes telephoniques en 
parallele. 

Selon les modeles, il faut en outre installer le pilote de la carte, fourni par le constructeur, 
permettant au systeme d' exploitation de la reconnaitre comme nouveau peripherique 
materiel et de la rendre disponible et configurable avec Asterisk. 

La societe Digium, qui maintient le logiciel Asterisk, assure la vente de ces composants 
a des tarifs competitifs. D'autres societes proposent des cartes analogues, mais leur 
compatibility avec les composants vendus pas Digium n'est pas toujours garantie. 

On distingue les deux formats d' interface suivants : 

• FXS (Foreign eXchange Subscriber), qui permet le branchement d'un telephone 
analogique sur le serveur Asterisk. Si Ton ne souhaite pas investir dans 1' achat 
d'equipements purement IP, il est possible d'utiliser son telephone analogique habi- 
tuel en le reliant au serveur Asterisk par le biais d'une carte FXS. La carte assure la 
fonctionnalite de conversion dans les deux sens d'un signal numerique en un signal 
analogique. 

• FXO (Foreign eXchange Office), qui permet le branchement du serveur Asterisk sur 
une ligne telephonique classique. Pour interagir ave le monde RTC et depasser le cadre 
du reseau purement IP, cette carte assure la jonction avec la telephonie RTC. Elle joue 
le role de passerelle en faisant communiquer tout utilisateur connecte a Asterisk avec 
des utilisateurs connectes au reseau RTC. 

Dans le cas ou Ton souhaite supporter la connectivite avec le reseau telephonique RTC, 
il est necessaire d'installer les drivers Zaptel et Libpri. Tous deux concernent la gestion 
des cartes FXO/FXS avec Asterisk pour des composants de type Zaptel ou « Zaptel 
compliant », c'est-a-dire conformes aux composants de type Zaptel, sans etre pour autant 
standards. 



Attention ! 

II est indispensable d'installer ces modules avant ('installation du serveur Asterisk proprement dit. En effet, 
ces pilotes etant dependants de composants materiels, le serveur doit les prendre en compte lors de sa 
compilation et ne peut les integrer par la suite. Si le serveur Asterisk a deja ete installe, il est necessaire, 
apres avoir compile et installe les pilotes Zaptel et Libpri, de revenir a I'etape de compilation du serveur. 
Cette derniere peut alors prendre en compte le chargement des pilotes. 



Telecharger les composants utiles 

Les composants d' Asterisk se presentent sous forme d'archives portant l'extension 
.tar.gz et non de flchiers binaires, qu'il faut compiler puis installer manuellement. 

l.Commen^ons par telecharger la derniere version disponible du logiciel Asterisk, a 
l'adresse http://www.asterisk.org/download (ou ftp://ftp.digium.com/pub/). Le site est en anglais, mais 
la section de telechargement (download) est facilement identifiable. Comme le logiciel 
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est libre et assez repandu, il dispose de multiples miroirs, dont un moteur de recherche 
fournira rapidement les liens. On y trouve les modules recapitules au tableau 12.1. 



Module 

Asterisk 

Asterisk-addons 
Asterisk-sounds 



Libiax 

Libpri 
Zaptel 



Tableau 12.1 - Principaux modules du logiciel Asterisk 

Description 

Coeur du logiciel, ce programme est le seul veritablement indispensable a son fonctionne- 
ment. II est done indispensable de le telecharger. 

Ce paquetage comporte le code source du logiciel Asterisk, ainsi que plusieurs modules 
complementaires qui peuvent se reveler utiles. II est vivement recommande de I'installer. 

Ces modules sont fournis sur plusieurs fichiers de paquetage. lis fournissent une quantite de 
sons qui peuvent etre utilises dans des messages d'accueil ou pour signaler a I'appelant diver- 
ses informations. Ces messages audio sont disponibles en trois langues, anglais, espagnol et 
frangais, et sous plusieurs formats de codec, comme G.71 1 , G.722, G.729 et GSM. L'utilisation 
de ces sons n'etant pas limitative, il est possible, en respectant les formats supportes par Aste- 
risk, d'en ajouter de sa propre composition ou issus d'autres sources . Ces paquetages ne sont 
pas indispensables, mais seulement pratiques, lis peuvent etre ajoutes ulterieurement. 

Cette bibliotheque de codes source pour les communications utilisant le protocole IAX n'est 
pas indispensable. Elle est surtout destinee au developpement de clients IAX. Nous revien- 
drons, plus loin dans ce chapitre, sur le protocole IAX. 

Cette bibliotheque est utilisee pour assurer I'interface avec differents types de reseaux non-IP. 

Ce paquetage contient les pilotes permettant de prendre en charge les cartes d'interface 
avec les reseaux non-IP. La section qui suit presente les cas ou il est indispensable d'installer 
ce composant. 



Remarque 

Au lieu de telecharger les sources au format archive, il est possible de telecharger un installeur du logiciel. 
L'installeur a I'avantage d'etre totalement automatise, et il evite de devoir decompresser puis installer 
manuellement le logiciel. Neanmoins, il est propre a une distribution particuliere, ce qui implique de trou- 
ver l'installeur adequat. Ce dernier se presente le plus souvent comme un fichier portant I'extension .rpm 
pour les distributions Redhat et Mandriva ou .deb pour Debian. Les habitues pourront preferer cette 
methode a celle que nous presentons, qui reste independante de la distribution utilisee. 



Decompresser les sources 

Une fois les telechargements termines, on peut ouvrir un terminal, se placer a 1' emplace- 
ment ou les archives ont ete telechargees puis saisir la commande qui suit pour chacune 
des archives que Ton a recuperees : 

tar -xzvf nom_du_composant_a_installer 



nom_du_composant_a_installer represente le nom de 1' archive telechargee. Chacune des 
archives a ete decompressee dans un repertoire portant le nom du composant. Les sons 
n'ont pas besoin d'etre installes ; il suffit, une fois l'installation effectuee, de les placer 
dans le repertoire de sons d' Asterisk (par defaut /var/lib/asterisk/sounds). Par contre, 
les autres programmes, doivent etre installes. 
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Installer les programmes 

Les commandes suivantes permettent d'effectuer la compilation et 1' installation d'un 
composant : 



cd nom_du_ 


.repe 


rt 


oi re. 


_du_ 


_composant_ 


_a_ 


jnsta 


11 


er 


make 






















make 


inste 


11 



















La premiere ligne permet de se placer a l'interieur de repertoire qui a ete decompresse 
precedemment, la seconde lance la compilation du programme et la troisieme lance son 
execution. Les memes commandes sont a reproduire pour chacun des composants, en se 
pla^ant chaque fois dans le repertoire adequat. 



Important 

II faut respecter I'ordre d'installation des composants. Si Ton souhaite les utiliser, les modules Libpri et 
Zaptel doivent imperativement etre installes avant le serveur Asterisk. Le module Asterisk-addons peut 
etre installe a la fin. 



Lancement du serveur et exploitation 

L'etape d'installation achevee, il faut la tester en lan^ant le serveur Asterisk, afm de verifier 
son bon fonctionnement. 

Asterisk n' impose pas de fonctionnement par defaut. II ne dispose d'ailleurs pas de 
flchier de configuration preetabli lui conferant initialement un modele de fonctionne- 
ment. La maniere dont les appels telephoniques sont diriges n'est done pas encore speciflee. 
A ce stade, le serveur n'est pas exploitable. 

Pour l'utilisateur debutant, il est preferable de commencer en partant d'une base de 
flchiers que Ton adaptera par la suite selon ses besoins. Nous allons demander a Asterisk 
de nous preparer une configuration initiale. Pour cela, nous utilisons un terminal, et nous 
nous pla^ons dans le repertoire source d' Asterisk (celui dans lequel nous avons lance 
l'installation), pour saisir la commande suivante : 

make samples 

A present, des flchiers standards sont generes et exploitables. 



Remarque 

Cette commande est utilisable a tout moment pour revenir a un etat de base dont la configuration est 
valide, sans avoir a lancer une nouvelle installation du serveur. C'est une configuration de reference. 
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Dans cette section, nous n'allons pas modifier les fichiers de configuration, mais simple- 
ment lancer le serveur Asterisk. A la section suivante, nous montrerons comment person- 
naliser les fichiers de configuration afin de gerer des services. 

II existe deux modes differents de lancement d' Asterisk, le mode serveur et le mode client : 

• Mode serveur. C'est le mode de fonctionnement principal, dans lequel le serveur se 
met en ecoute des clients et prend en charge leur demande de connexion et de commu- 
nication. 

• Mode client. Le client Asterisk permet de se brancher au serveur Asterisk et de l'inter- 
roger pour lui demander des informations sur son etat courant, ou bien pour lui donner 
de nouvelles directives qui seront prises en compte dynamiquement et modifieront son 
comportement. 

Le mode client nous servira dans les sections suivantes a valider le fait que le serveur est 
correctement lance et disponible. II s'agit done d'un outil d' administration interactif prati- 
que, sans qu'il soit pour autant indispensable. Le lancement en mode client n'est possible 
que si une instance d' Asterisk en mode serveur a ete prealablement effectuee. 

Chacun de ces deux modes est obtenu par le biais de la commande asterisk, mais avec 
des arguments de commande differents dans chaque cas. 

Lancer Asterisk en mode serveur 

Le mode serveur d' Asterisk peut etre lance de deux fa^ons, selon que nous souhaitons un 
lancement automatique (a chaque demarrage du systeme d' exploitation) ou manuel 
(uniquement pendant la session courante). 

Pour un lancement automatique du serveur, la commande est la suivante : 

/usr/sbin/safe_asterisk 



Pour un lancement manuel, la commande devient : 

asterisk -vvvc 

La succession des options v fournit un niveau de messages informatifs concernant le 
fonctionnement du serveur de plus en plus eleve. vvv est en fait l'acronyme de very very 
verbose. La lettre c demande qu'un message (indiquant que la console de controle 
d' Asterisk est bien activee) s'affiche devant chaque ligne. Le message est generalement 
*CLI> (pour Command Line Interface). 

Se connecter a Asterisk en mode client 

Une fois le serveur Asterisk demarre, nous pouvons verifier qu'il est operationnel grace 
au client Asterisk. Ce dernier se connecte pour cela au serveur Asterisk afin de recuperer 
toutes sortes d' informations d'etat du serveur et de connexion des utilisateurs. 
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II est aussi possible de saisir des commandes d' administration arm de modifier le 
comportement courant du serveur. Pour executer le mode client d' Asterisk (on parle 
aussi de mode interactif), il sufflt d'entrer la commande suivante dans un terminal : 

asterisk -r 



Remarque 

Des que cette commande est lancee, le client Asterisk se connecte au serveur Asterisk. Ce dernier est a 
I'ecoute de requetes de parametrage et de gestion des connexions dont il a la charge. Ces requetes sont 
effectuees au moyen d'une interface en ligne de commande, ou CLI (Command Line Interface). Pour 
connaitre la liste des commandes disponibles, il suffit d'entrer la commande help. 
Pour disposer d'informations plus completes, la commande set verbose permet de recuperer les journaux. 



Nous pouvons done interroger le serveur pour en obtenir differentes informations, dont 
voici quelques exemples utiles : 

• Savoir qui est connecte. Permet de connaitre 1' ensemble des utilisateurs (ou peers) 
connectes, selon le protocole qu'ils utilisent. Ce ne sont pas des utilisateurs forcement 
en cours de communication, mais simplement des utilisateurs connectes au serveur 
Asterisk, et done joignables. Pour connaitre les utilisateurs connectes qui utilisent le 
protocole SIP, on utilise la commande sip show peers, comme ci-dessous : 




De maniere analogue, les utilisateurs qui utilisent le protocole IAX peuvent utiliser 
la commande iax2 show peers, comme ci-dessous : 



asterisk*CLI> 


iax2 show peers 








Name/Username 




Host 




Mask 


Port 


Status 


202/202 




192.168.1.2 


(D) 


255.255.255.255 


4569 


Unmonitored 


204/204 




192.168.1.4 


(D) 


255.255.255.255 


4569 


Unmonitored 


206/206 




192.168.1.6 


(D) 


255.255.255.255 


4569 


Unmonitored 


207/207 




192.168.1.7 


(D) 


255.255.255.255 


4569 


Unmonitored 


4 iax2 peers 

1 


[0 


online, offline 


, 4 unmonitored] 
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Recharger les informations d'un flchier de configuration. Les fichiers de configuration 
sont en principe charges au lancement du serveur Asterisk. II est possible de les 
recharger dynamiquement pendant que le serveur Asterisk tourne, sans avoir a le rede- 
marrer. 

Pour recharger 1' ensemble des fichiers de configuration, il sufflt de saisir dans 1' inter- 
face en ligne de commande la commande reload. Plus specifiquement, il est possible 
de ne charger que les modifications apportees a un flchier. De maniere generale, si le 
flchier a pour nom fichier.conf, il sufflt de saisir la commande fichier reload pour 
recharger ce flchier. Par exemple, pour recharger le flchier extensions.conf, nous 
entrons la commande extensions reload. De la meme maniere, la commande sip reload 
permet de recharger le flchier sip.conf. 



Configuration 

Le serveur Asterisk est a present operationnel. A ce stade, il n' assume encore aucune 
gestion des appels. L' ensemble des parametres garantissant son mode de fonctionne- 
ment, et plus generalement son comportement pour la gestion des appels, se traduit par 
un ensemble de fichiers de configuration. 

Plusieurs interfaces permettent de modifier ces fichiers. Quoique plus conviviales, ces 
interfaces n'en demeurent pas moins limitatives en comparaison des possibilites offertes 
en modiflant directement les fichiers de configuration. C'est pourquoi nous preferons 
presenter ces derniers. 

Les quatre categories d'elements d' Asterisk 

Nous presentons ici les notions fondamentales du fonctionnement d' Asterisk. Pour 
comprendre et maitriser le logiciel, il est indispensable de maitriser ces notions avant de 
se lancer dans la configuration. 

La configuration du serveur Asterisk comporte les quatre categories d'elements suivants : 

• Description des utilisateurs et des terminaux. Pour etre joignable, les utilisa- 
teurs (s'ils se connectent en utilisant un programme logiciel de type softphone) 
comme les terminaux (si les utilisateurs se connectent avec des composants mate- 
riels) doivent etre identiflables. Un identiflant, qui peut etre quelconque (sous 
forme de chaines de carac teres avec des chiffres ou des lettres), doit etre affecte a 
chaque utilisateur (ou terminal). Une authentiflcation peut etre ajoutee pour 
s'assurer de l'identite des utilisateurs (ou terminaux) et preserver le systeme des 
utilisations frauduleuses. Les utilisateurs (et les terminaux) sont recenses dans des 
fichiers differents selon le protocole de signalisation qu'ils exploitent (SIP, H.323, 
IAX, etc.). 
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• Plan de numerotation (ou dial plan). Apres avoir generer les comptes des utilisa- 
teurs, il faut ensuite determiner de quelle maniere ils vont communiquer, c'est-a-dire, 
d'abord, quel est le numero de telephone attribue a chaque terminal, mais aussi 
comment les appels et les services s'effectuent. La notion de plan de numerotation 
correspond precisement aux regies de routage des appels qui regissent le fonctionne- 
ment du systeme et permettent la mise en relation les interlocuteurs. II convient de les 
programmer et de les analyser en profondeur, car elles concentrent 1' intelligence de la 
plate-forme. En specifiant la maniere de reagir aux appels, le systeme fournit un 
premier niveau de service aux utilisateurs : le routage des communications. Un flchier 
unique definit le plan de numerotation (extensions.conf), lequel peut eventuellement 
appeler d'autres fichiers par inclusion. 

• Description des services supplementaires. Les services supplementaires permettent 
d' assurer toutes sortes de fonctionnalites, telles que la messagerie telephonique ou la 
journalisation des appels. Chaque service est defini dans un flchier speciflque, dont 
nous donnerons quelques exemples. 

• Description du materiel physique. Si nous restons dans un reseau purement IP, aucun 
autre materiel qu'un ordinateur n'est necessaire. Des lors que nous souhaitons corres- 
ponds avec des utilisateurs du reseau telephonique commute ou de tout autre reseau 
non-IP, nous devons recourir a des equipements specifiques. La description du materiel 
permet d'indiquer au serveur Asterisk la nature de ces composants, de fa^on qu'il en 
tienne compte. Les fichiers etant differents selon le materiel considere, le serveur Asterisk 
doit etre recompile avec le chargement de ces fichiers. 

Chacun de ces elements est decrit par un ou plusieurs fichiers. La separation de ces 
fichiers apporte une modularite a la gestion de la plate-forme. Nous decrivons a la section 
suivante les fichiers utilises et la maniere de les programmer. Puis, dans les sections 
suivantes, nous detaillerons les categories d' elements precedemment mentionnees pour 
expliquer successivement comment s'effectuent la description des utilisateurs et des 
terminaux, puis la programmation du plan de numerotation et enfln la mise en place de 
services complementaires. 

Organisation des fichiers (fichier asterisk. conf) 

Les fichiers d' Asterisk sont repartis dans plusieurs repertoires afln de suivre l'organisa- 
tion classique des systemes Linux. Le repertoire contenant les executables binaires du 
serveur Asterisk et ses composants principaux est situe par defaut dans le chemin /usr/ 
bin/. II comporte les commandes principales suivantes : asterisk, astman, astgenkey, 
safe_asterisk. 

Pour tous les autres fichiers non binaires, le flchier asterisk.conf offre une grande 
souplesse d'utilisation et laisse 1' administrateur libre de modifier sa configuration par 
defaut, en specifiant 1' emplacement dans l'arborescence du systeme de fichiers utilise. 



Pratique de la TolP 



Parte II 



En 1' absence de ce fichier, les chemins par defaut sont consideres, comme dans l'extrait 
ci-dessous : 




Le tableau 12.2 recapitule les descriptions correspondant aux differentes directives utili- 
sables dans le fichier asterisk.conf. 



Tableau 12.2 - Directives indiquant ('emplacement des repertoires d' Asterisk 



Directive 

astetcdir 

astmoddir 
astvarlibdir 



astagidir 



astspooldir 



astrundir 



astlogdir 



Description 

Specifie le repertoire contenant I'ensemble des fichiers de configuration (portant I'extension 
.conf). 

Specifie le repertoire contenant I'ensemble des modules (portant I'extension .so). 

Specifie le repertoire contenant I'ensemble des bibliotheques exploitables, fournissant notam- 
ment une galerie de fichiers audio qui peuvent etre utilises dans des services avec des annonces 
automatisees du serveur (mise en attente, messagerie, annonces d'accueil, etc.) et seront appe- 
les par leur nom dans la programmation de ces services. 

Specifie le repertoire contenant I'ensemble des scripts AGI (Asterisk Gateway Interface), four- 
nissant des fonctionnalites complementaires implementees avec un langage de programmation 
tel que Shell, C, PHP, Perl ou Pascal. 

Specifie le repertoire contenant I'ensemble des enregistrements audio qui sont realises par le 
serveur Asterisk, notamment pour la messagerie vocale, mais aussi pour I'enregistrement de 
communications, de conferences, etc. 

Specifie le repertoire contenant le fichier de PID (Process ID) d'Asterisk identifiant de maniere 
unique le processus en charge de la gestion du serveur, qu'il est possible de suivre parmi les 
autres processus. 

Specifie le repertoire contenant I'ensemble des fichiers journaux sauvegardant les evenements 
survenus et le traitement qui leur a ete applique. II est important de verifier que ce repertoire ne 
devienne pas rapidement trop volumineux pour surcharger les capacites du serveur. 



A la suite de la section [directories], on trouve une section [files] qu'il est vivement 
recommande de ne pas modifier. Elle comporte des informations de securite, en particulier 
les droits restreignant l'acces au serveur Asterisk. 
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La section suivante detaille les principaux fichiers de configuration generale qu'il 
convient de connaitre. De maniere generale, un commentaire peut etre insere dans ces 
fichiers de configuration en le faisant preceder d'un point- virgule. 



Attention ! 

Les fichiers ne sont pas interprets dynamiquement. Autrement dit, pour qu'une modification effectuee 
dans un fichier soit prise en compte par le serveur en cours de fonctionnement, il est necessaire de lui 
imposer un rechargement de ces fichiers par la commande reload (introduite a la section presentant la 
connexion en mode client a Asterisk). 



Premiere etape de configuration : Description des utilisateurs 
et des terminaux (fichiers sip.conf, iax.conf, mgcp.conf, h323.conf, 
skinny.conf) 

La premiere etape de configuration du serveur Asterisk correspond a la definition des 
comptes d' utilisateurs et des terminaux. Ceux-ci sont identifies par le protocole de signali- 
sation qu'ils utilisent. II existe done un fichier de configuration par protocole de signalisation 
supporte. 

A ce stade, les numeros de telephone ne sont pas associes aux comptes des utilisateurs 
et aux terminaux. II faudra attendre la programmation du plan de numerotation pour 
mettre en place ces associations (voir l'exemple numero 1, a la fin de la section 
suivante). Cette distinction entre un utilisateur (ou terminal) et son numero offre une 
meilleure visibilite en regroupant les attributions de numeros, independamment des 
parametres des comptes. 

On notera que, de la meme maniere qu'on declare un compte d'utilisateur lorsque celui- 
ci se connecte avec un softphone, il est possible de declarer des telephones physiques 
pour autoriser leur connexion dans le pare gere par Asterisk. On procedera pour cela de 
maniere analogue, en declarant un compte, et les proprietes associees a ce compte, 
comme on le ferait pour un utilisateur. 

Nous detaillons dans les sections suivantes les fichiers sip.conf et iax.conf. 

Le fichier sip.conf 

Le fichier sip.conf permet de definir tous les utilisateurs SIP. II est segmente en sections, 
dont chacune debute par une etiquette fie label) entre crochets. 

Le label special [general] permet d'attribuer des valeurs a des parametres generiques, 
tels que le port utilise. Le label [user_id] definit chaque compte d'utilisateur. 
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Voici un exemple de fichier sip.conf, dans lequel deux utilisateurs sont declares 



[general ] 
port=5060 

[david] 

username=David 

secret=slp@st3rlsk! 

callerid="David" <5551> 

type=friend 

host=dynamic 

nat=yes 

canreinvite=no 

context=internal 

di sal 1 ow=al 1 

al low=ul aw 

al low=gsm 

allow=h263 

[laurent] 

type=friend 

host=dynamic 

context=internal 

username=l_aurent 

nat=yes 

canreinvite 

secret=hl02m3E 

callerid="Laurent" <5552> 

La section [general] indique le numero de port utilise par tous les utilisateurs, soit ici 
5060. Les sections suivantes renseignent les parametres de deux compte d'identiflant 
david et laurent. Les parametres les plus utilises pour la definition de ce compte sont 
recapitules au tableau 12.6. Comme on le voit dans l'exemple, tous ne sont pas obli- 
gatoires (lorsqu'ils sont optionnels, des valeurs par defaut sont pratiques si les para- 
metres ne sont pas presents), et l'ordre dans lequel ils sont donnes n'a aucune impor- 
tance. 
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Parametre 

username 

secret 

type 



host 



callerid 






context 

language 
allow 

disallow 
nat 

canreinvite 



mailbox 
dtmfmode 



Tableau 12.6 - Parametres decrivant un compte d'utilisateur 

Description 

Identifiant de I'utilisateur 

Mot de passe associe au compte 

Indique le type de compte, et les restrictions associees. On distingue trois types de comptes : 

- Friend /permet d'appeler et d'etre appele (autorise les appels entrants et sortants). 

- User /permet seulement d'etre appele (appels entrants). 

- Peer /permet de definir une liaison entre deux terminaux seulement. 



Specif ie une adresse IP a partir de laquelle I'utilisateur peut acceder a son compte. La valeur dyna- 
mic autorise une adresse IP fournie dynamiquement, par un serveur DHCP notamment. Cette 
valeur est done moins restrictive. 

Norn de I'utilisateur, entre guillemets, suivi de son extension telephonique, e'est-a-dire de son 
numero d'appel (au format de la RFC 822). 

Attention : le numero de telephone mentionne ici ne constitue pas une association du numero avec 
I'utilisateur (cette association sera faite ulterieurement). Ce parametre permet simplement d'identi- 
fier I'utilisateur (ou le terminal) lorsqu'i I passe des appels. Autrement dit,cette information est utili- 
sed dans les appels sortants uniquement pour indiquer le nom (si le terminal appele permet 
d'afficher cette information) et le numero de telephone de I'utilisateur. 

Specifie le type de routage a appliquer pour I'utilisateur. Le type de routage correspond a un 
contexte defini dans le plan de numerotation (fichier extensions.conf). Les communications avec 
cet utilisateur sont done soumises au contexte du meme nom dans le fichier extensions.conf. 

Specifie la langue utilisee pour les fichiers audio. 
Par exemple : language=fr. 

Liste les codecs autorises par I'utilisateur de ce compte. 

Par exemple, pour autoriser le codec G.71 1 , selon la loi mu, on saisira: allow=ulaw. 

Ce meme parametre est aussi valable pour specifier les codecs video (par exemple : allow=h263)\\ 

est possible d'en mentionner autant que Ton souhaite, en repetant ce parametre autant de fois. 

Interdit les codecs qui sont mentionnes a sa suite. Une valeur possible de ce parametre est all. Dans 
ce cas, aucun codecs ne sera utilisable par I'utilisateur concerne, sauf ceux specifies explicitement 
dans le (ou les) parametre(s) allow. 

Precise si les flux traversant un reseau utilisent la translation d'adresse (NAT). La valeur du para- 
metre nat est yes ou no. 

Ce parametre est souvent indispensable car I'utilisation du nat est classique, meme chez les parti- 
culiers. 

Ce parametre peut prendre les valeurs yes ou no. Si sa valeur est fixee a yes, Lorsqu'une commu- 
nication est en train de s'etablir le serveur Asterisk va recuperer des informations (notamment vers 
qui envoyer les flux) et ils les reemettra dans un nouveau message d'invitation une fois que la com- 
munication sera acceptee seulement. 

Attention, si I'utilisateur se trouve derriere un NAT, il est indispensable de mettre la valeur de ce 
parametre a no pour laisser passer les flux multimedia correctement, car le nouveau message 
d'invitation du serveur Asterisk ne tiendrait pas compte du NAT. 

Indique la boite vocale associee a ce compte. Nous detaillons ce parametre et son utilisation a la 
section qui traite de la messagerie audio. 

Ce champ indique le type de tonalite DTMF qui sera applique. Les valeurs possibles sont inband, 
rfc2833, info ou auto 
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Le fichier iax.conf 

Les clients utilisant le protocole de signalisation IAX sont mentionnes dans le fichier 
iax.conf. Son fonctionnement et sa description sont semblables a ceux du fichier 
sip.conf. 

Voici un exemple de fichier iax.conf definissant un utilisateur : 

[general ] 
bindport=4569 

[1234] 

username=1234 

type=friend 

host=dynamic 

context=internal 

callerid="Guy" <1234> 

La aussi, comme pour le fichier sip.conf et contrairement a ce qu'on pourrait croire, les 
nombres ne sont pas des affectations de numeros de telephones a des utilisateurs. Ce ne 
sont que des identifiants de comptes. Seul le plan de numerotation permet de realiser la 
correspondance d'un numero de telephone avec un utilisateur. 

Deuxieme etape de configuration : 

le plan de numerotation (fichier extensions.conf) 

Une fois les comptes des utilisateurs et des terminaux dermis, il faut leur attribuer des 
numeros de telephone pour qu'ils soient joignables. II faut aussi determiner la procedure 
qui s'enclenchera lors de chaque appel (par exemple, si l'appel sera transmis vers deux 
postes en meme temps, s'il sera redirige vers une messagerie au bout d'un laps de temps, 
si l'appel sera journalise dans une base de donnees, etc.). 

II faut enfin definir les services speciaux que Ton souhaite activer (par exemple le service 
de messagerie, les serveurs vocaux disponibles, les salons de conference mis en place, 
etc.). Tout cela s'effectue au moyen d'un unique composant : le plan de numerotation. 

Le plan de numerotation, ou dial plan, est 1' element central de la configuration du 
serveur Asterisk. II definit le comportement du serveur PBX. Maitre de ceremonie ou 
chef d'orchestre, c'est lui qui regit les actions a entreprendre, dans quel ordre et dans quel 
cas, que ce soit pour un utilisateur donne ou pour l'ensemble des utilisateurs. 

Ce plan concentre toute 1' intelligence et la logique de fonctionnement du reseau tele- 
phonique. C'est pourquoi il est indispensable d'en maitriser a la fois la syntaxe et la 
semantique. II est constitue d'un ensemble de regies, dont chacune pose les conditions de 
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son application, ainsi que, lorsque ces conditions sont reunies, les traitements qui seront 
appliques. 

Le plan de numerotation est defini dans un fichier unique dont le nom est exten- 
sions.conf. Sous Linux, et avec une installation standard, ce fichier se trouve generalement 
dans le repertoire /etc/asterisk/. 

Le plan de numerotation repond a la question : que doit faire le serveur PBX Asterisk 
lorsqu'il re^oit le flux telephonique d'un utilisateur ? La reponse est fournie sous forme 
de regies qui sont structurees et dont la syntaxe est deflnie par les quatre elements 
suivants : 

• le contexte 

• 1' identiflant d' extension 

• la priorite 

• 1' application 

Ces elements decrivent les criteres que les flux doivent verifier et le traitement qui leur 
sera applique le cas echeant. 

Le format general d'un plan de numerotation, dans lequel se combinent ces quatre 
elements, est le suivant : 



[contexte_l] 








exten => identifiant_d 


extension_l, 


priori te_l, 


application^ 


exten => identifiant_d 


extension_2, 


priori te_2, 


appl ication_2 


exten => identifiant_d 


extension_3, 


priori te_3, 


application_3 


[contexte_2] 








exten => identifiant_d 


extension_4, 


priori te_4, 


appl ication_4 



On distingue dans cet exemple deux contextes differents, signales par [contexte_l] et 
/ contexte _2]. Le mot-cle exten est utilise pour deflnir une extension. II est suivi d'une 
fleche, formee par les symboles = et >. 

Dans notre exemple, trois extensions sont deflnies dans le premier contexte, et une dans 
le second. Chaque extension comporte un identiflant d' extension (identi- 
fiant_d 'extension _i), un numero de priorite (priorite _i) et une fonction applicative 
(application^). Chacun de ces criteres permet de preciser qui est 1' appelant, avec quel 
service (ou personne) il souhaite etre mis en relation et comment effectuer la fourniture 
de ce service. 

Nous pouvons lire la premiere regie comme suit : « Lorsque 1' extension identi- 
flant _d_extension_l se presente dans le contexte contexte _1, nous executons Taction 
application^ avec la priorite priorite_l ». II est necessaire de maitriser ces elements 
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pour affecter un numero de telephone a un utilisateur (ou a un terminal) et plus generale- 
ment pour determiner la maniere dont les appels se deroulent. Les sections suivantes 
precisent le role de chacun de ces quatre elements. 

D'abord le contexte 

Le plan de numerotation est organise en sections appelees contextes. Un contexte definit 
un cadre d' application. Par exemple, si un utilisateur compose le chiffre 5 sur son poste 
telephonique, ce numero est intercepts par le serveur Asterisk, lequel peut interpreter 
differemment ce numero selon differentes situations, notamment les suivantes : 

• Si l'utilisateur ne consulte aucun service, le chiffre 5 peut corresponds au numero de 
telephone abrege que le serveur a enregistre pour un de ces contacts. 

• Si l'utilisateur a prealablement demande a effectuer un appel longue distance, le 
chiffre 5 peut etre le premier d'un code d'authentification permettant la mise en 
relation. 

• Si l'utilisateur est en relation avec un service vocal, le chiffre 5 peut correspondre au 
choix d'un service specifique parmi ceux proposes. 

• Si l'utilisateur est en train de consulter son repondeur heberge par le serveur Asterisk, 
le chiffre 5 peut etre un code de commande pour demander au serveur de reecouter un 
message. 

• Si l'utilisateur est en cours de communication avec un contact, le chiffre 5 peut 
demander au serveur Asterisk de lancer l'enregistrement de la conversion en cours. 

Le serveur Asterisk ne doit done pas interpreter de la meme fa^on toutes les saisies effec- 
tuees sur un terminal telephonique, mais distinguer les cas de figure. Dans notre exemple, 
les contextes correspondent a l'etat dans lequel l'appel s'inscrit : l'utilisateur peut etre en 
ligne, non authentifie, en relation avec le service vocal, en relation avec un service de 
messagerie vocale ou en cours de communication. D'ou nos cinq contextes. 

Pour savoir quel contexte utiliser lors d'un appel, le plan de numerotation se fonde sur les 
elements suivants : 

• Identite de 1' appelant ou de l'appele, auquel il est possible d'attribuer des contextes 
particuliers. 

• Actions entreprises par les utilisateurs pendant un appel : la saisie de touches par un 
utilisateur peut engendrer des branchements conditionnels ou inconditionnels 
(presentee plus loin avec les structures goto et gotolf). 

De la meme maniere, les contextes permettent de gerer des categories d'utilisateurs. 
Nous pouvons, par exemple, definir un contexte pour les employes commerciaux autori- 
ses a passer des appels longue distance, et un autre pour les employes ingenieurs unique- 
ment autorises a passer des appels locaux. Dans un cadre domestique, nous pouvons defi- 
nir un contexte pour les personnes adultes, dans lequel tous les appels sont possibles, et 
un autre pour les enfants, dans lequel seuls des numeros d' appel predefinis sont possibles. 
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La puissance du serveur Asterisk reside dans cette capacite de personnalisation, qui peut 
concerner un utilisateur ou un service speciflque, comme dans les cas suivants : 

• Un utilisateur peut disposer de services differents de ceux disponibles pour un autre 
utilisateur. Par exemple, si le poste d'un utilisateur est indisponible au bout de cinq 
sonneries, l'appel peut etre redirige vers le poste d'un autre utilisateur, tandis que le 
meme cas de figure pour un autre utilisateur declenche la messagerie. 

• Tous les services etant personnalisables par radministrateur, un administrateur peut 
decider que la messagerie des utilisateurs se declenche au bout de cinq sonneries, alors 
qu'un autre peut decider qu'elle ne s'active qu'au bout de sept sonneries. 

A chaque contexte, une politique de gestion particuliere peut etre deflnie sous la forme 
d'une ou plusieurs extensions. Chaque contexte regroupe un ensemble d'extensions 
constitutes d'un identiflant d' extension, d'une priorite et d'une application. 

Les contextes particuliers 

II existe deux contextes particuliers, appeles [general] et [globals] et tous deux places au 
tout debut du flchier extensions.conf. 

[general] 

Toujours mentionnee avant les autres, cette section permet de deflnir des options genera- 
les appliquees par le serveur Asterisk au plan de numerotation. Par exemple, on peut 
indiquer a la suite de la section : 

i 1 

clearglobal vars=yes 

Cela a pour effet d'effacer 1' ensemble des variables globales enregistrees par le serveur 
Asterisk. Au contraire, la valeur no a pour effet de conserver aux variables globales des 
valeurs persistantes a chaque rechargement du serveur, meme si elles ne sont plus speciflees 
dans les flchiers de configuration. 

De meme, en mentionnant : 

static=yes 
writeprotect=no 



il est possible de sauvegarder le plan de numerotation par l'interface de controle (CLI) 
d' Asterisk presentee precedemment. 

II est egalement vivement recommande de choisir : 

autofallthrough=yes 
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Cette valeur, prise par defaut dans les versions recentes d' Asterisk, permet de terminer 
automatiquement un appel pour lequel tous les traitements mentionnes dans le plan de 
numerotation ont ete effectues. A defaut, si ce parametre a pour valeur no, le serveur 
attend, une fois tous les traitements effectues, que l'utilisateur effectue une nouvelle 
saisie. 

[globals] 

La section [globals] permet de deflnir toutes les variables globales susceptibles d'etre 
utilisees dans la suite du fichier. Nous verrons plus loin comment deflnir de telles 
variables. 

Ensuite, I'identifiant d'extension 

Au sein de chaque contexte, des regies permettent de deflnir le comportement a adopter, 
autrement dit la maniere dont le routage et le service doivent etre rendus. 

L'identiflant d'extension deflnit la destination d'un appel. En premiere approxima- 
tion, c'est le numero d'un poste appele. Nous verrons que cela peut aussi etre un 
service determine ou un choix dans un menu vocal. II correspond done a un numero 
(ou a un nom) d' appel, attribue indifferemment a une personne physique ou a un 
service automatise. 

A titre d'exemple, le tableau 12.3 donne quelques identiflants d'extension avec leur assi- 
gnation respective. 

Tableau 12.3 - Exemples d'identifiants d'extension 



Identifiant d'extension 


Description 





Accueil 


5 


Repondeur telephonique 


101 


Poste telephonique d'Albert 


102 


Poste telephonique de Beatrice 


103 


Poste telephonique de Caroline 



Le choix des identiflants d'extension est laisse a la convenance de l'administrateur. Les 
identiflants peuvent etre formes de chiffres (comme pour un numero de telephone classique) 
ou de lettres (comme le nom d'une personne ou d'un service). 



Remarque 

Les espaces sont prohibees. En cas d'utilisation d'espaces, le comportement du systeme devient imprevi- 
sible, meme si aucune erreur n'est retournee. 
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Les utilisateurs peuvent etre identifies par leur adresse e-mail. Si l'identiflant d'extension 
comporte des lettres, cela implique que le terminal appelant dispose du materiel adequat, 
de type clavier, pour saisir l'identiflant d'appel. On peut toutefois recourir a d'autres 
mecanismes, comme la reconnaissance vocale. 

Une regie ne peut etre atteinte que lorsque 1' execution de Taction relative a la regie 
precedente est terminee. Les raisons a cela sont, d'une part, que deux actions peuvent 
entrer en concurrence (diffusion d'un message sonore avec deux actions, dont la lecture 
conjointe rendrait les deux messages inaudibles), d' autre part, qu'une regie peut entrai- 
ner des sorties conditionnelles ou des sauts vers une autre regie selon un deroulement 
particulier (par exemple, la saisie d'un choix par 1' appelant peut entrainer une autre 
action que 1' absence de choix). 

Les extensions particulieres 

Asterisk deflnit quelques extensions particulieres permettant non pas de joindre un utili- 
sateur ou un service, mais de fournir un comportement explicite pour des situations parti- 
culieres. Les trois extensions predeflnies les plus courantes sont s, t et i. 

L'extension s 

Lorsqu'un flux telephonique parvient au serveur Asterisk, celui-ci peut lui appliquer un 
traitement indifferent de la personne ou du service que le flux tente de contacter. Pour 
cela, l'administrateur utilise l'extension s (pour le mot-cle start), qui indique que tous les 
flux (dans le contexte concerne) seront traites par la regie mentionnee. 

En voici un exemple : 

exten => s, 1, Playback (msg_attente) 

Tout appel soumis a cette regie lance un message audio nomme msg_attente pour indiquer a 
1' appelant que la communication est prise en compte et mise en attente. 

L'extension t 

Lorsqu'un certain delai (par defaut 10 secondes) s'ecoule sans qu'une extension ait ete 
saisie par l'utilisateur, l'extension t (pour le mot-cle timeout) est automatiquement appelee 
par le systeme. 

En voici un exemple : 

exten => t, 1, Playback (msg_del ai_depasse) 

Si un delai t (par defaut 10 secondes) s'ecoule, un message nomme msg_delai_depasse 
est automatiquement lance pour avertir l'utilisateur de l'attente d'une saisie par le 
systeme. 



Pratique de la TolP 



Parte II 



L'extension / 

Lorsque l'utilisateur saisit une extension qui n'est pas referencee dans le plan de nume- 
rotation, l'extension / (pour le mot-cle invalid) est automatiquement appelee par le 
systeme. 

En voici un exemple : 

exten => i, 1, Playback (msg_i rival i de) 

Si l'utilisateur saisit une extension inconnue, un message nomme msgjnvalide est auto- 
matiquement lance pour l'avertir de l'invalidite de sa saisie. 

Les filtres d'extension 

II est possible de definir des identiflants d'extension formes d'un filtre, ou pattern, qui 
represente une syntaxe generique d'identiflant. Cela permet d'offrir un service generique 
a des groupes d'utilisateurs ou des services specifiques. En particulier, cela permet de 
distinguer les appels locaux des appels internationaux en fonction des prefixes de nume- 
rotation. 

Tout filtre d'extension est precede d'un caractere de soulignement (underscore). Les 
caracteres speciaux permettant de definir un filtre sont dermis comme indique au 
tableau 12.4. 

Tableau 12.4 - Filtres d'extension 



Filtre 


Description 


chaine_quelconque 


Impose la presence de la chaine chaine_quelconque dans I'identifiant d'extension. 


[caracteres_quelconques] 


Remplace un caractere dans un identifiant d'extension parmi I'un de ceux mention- 
nes entre les crochets. 


X 


Remplace un chiffre entre et 9 dans un identifiant d'extension. 


Z 


Remplace un chiffre entre 1 et 9 dans un identifiant d'extension. 


N 


Remplace un chiffre entre 2 et 9 dans un identifiant d'extension. 


Remplace n'importe quel caractere ou serie de caracteres. C'est done un caractere 
joker qui ne devrait etre indique qu'avec un filtre suffisamment descriptif. 



La position des caracteres speciaux doit etre respectee pour corresponds a I'identifiant 
d'extension filtre. 

L' exemple suivant : 

0142XXXXXX 
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s' applique a n'importe quelle extension commen^ant par 0142 et ay ant une longueur de 
10 chiffres. 

L'exemple suivant : 

_0Z[12589]XXX 

s' applique a une extension ay ant pour premier caractere le chiffre 0, pour deuxieme 
caractere un chiffre entre 1 et 9, pour troisieme caractere un chiffre parmi les valeurs 1, 2, 
5, 8 ou 9, puis, pour les trois caracteres suivants (les trois symboles X), une valeur quel- 
conque entre et 9 et enfin pour le septieme caractere (le symbole point) un ou plusieurs 
chiffres quelconques. Au total, le numero fait un minimum de sept chiffres, le maximum 
n'etant pas mentionne. 

Le filtre _. (underscore suivi d'un point) remplace n'importe quel caractere ou serie de 
caracteres, autrement dit il s'applique a toutes les extensions. Ce filtre d'extension ne 
devrait done jamais etre utilise, puisqu'il est toujours verifie et s'applique sans restriction 
a tous les appels. 

Les extensions conditionnelles 

Une extension definit en principe le numero d'une personne ou d'un service a joindre, 
mais elle peut etre conditionnee par l'identite de la personne appelante. En effet, un 
meme numero d'appel peut donner lieu a des traitements differents. Par exemple, dans 
une entreprise, un unique numero d'appel pour un secretariat peut etre affecte a deux 
secretaires ayant chacune leur specialisation. Selon la personne appelant le secretariat, 
une redirection vers le poste le plus adequat peut s'effectuer. II suffit pour cela de 
mentionner le numero d'appel de la personne qui appelle juste apres 1' extension du 
service a joindre suivi d'un caractere slash. 

Par exemple : 

exten => 101/105, ... 

specifie une regie concernant l'appelant ayant pour identifiant 105 et appelant le poste 101. 

Les extensions conditionnelles peuvent utiliser des filtres, a la fois pour les identifiants de 
l'appele et ceux de l'appelant. 

Puis, la priorite 

La priorite definit l'ordre dans lequel la regie doit s'appliquer. Certains traitements 
necessitent plusieurs actions a entreprendre pour obtenir le comportement desire. Par 
exemple, si un correspondant ne repond pas, l'appelant peut etre redirige vers la messa- 
gerie de son correspondant. Dans ce cas, au moins deux etapes correspondent a un meme 
appel : la tentative d'appel vers le correspondant, puis la redirection vers la messagerie. 



Pratique de la TolP 



Parte II 



II faut ordonner chacune de ces etapes en mentionnant dans le plan de numerotation la 
priorite affectee a chacune des regies. 

La priorite est specifiee par une valeur numerique entiere debutant par la valeur 7. Plus la 
valeur attribute a une regie est faible, plus la priorite qui lui est concedee est importante. 
Les regies se succedent tour a tour avec un meme identiflant d' extension, selon un ordre 
croissant. 



Attention ! 

Si une priorite est oubliee (par exemple si Ton a une priorite 1 puis une priorite 3, et done qu'on a omis la 
priorite 2), le serveur ne peut poursuivre (done passer a la priorite 3 dans notre exemple). II importe de 
veiller a ce que I'ordre affecte a chaque regie n'omette pas une valeur. Lors d'une mise a jour, en particu- 
lier, il ne faut pas effacer une regie sans verifier la coherence et I'enchainement avec les priorites qui 
suivent. 



La priorite n 

II est possible d'optimiser la gestion des priorites en se flant a 1' emplacement d'ecriture 
des regies pour en fixer I'ordre. 

La notion de priorite numerique presente une contrainte delicate dans le maintien et la mise a 
jour des regies. Si nous souhaitons ajouter une nouvelle regie entre deux regies, il est neces- 
saire de modifier explicitement toutes les priorites des regies qui suivent la regie ajoutee. 

Considerons la succession de regies suivantes : 




Les applications specifiees action_i sont quelconques. Apres la premiere regie, nous 
souhaitons ajouter une nouvelle regie executant Taction action_nouvelle. Nous modifions 
comme suit la sequence precedente : 




Cette maniere de proceder est contraignante en ce qu'elle impose chaque fois de verifier 
la coherence des ordonnancements. Asterisk propose une maniere plus simple de gerer 
les priorites grace a la priorite n. Le n specifie Taction suivante (en anglais next). Avec 
une priorite n, les etapes sont suivies selon leur ordre d' apparition dans la sequence du 
plan de numerotation. 
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L'exemple precedent initial devient ainsi : 




L'ajout de la nouvelle regie donne simplement : 



exten => 98765, 


1, 


action_l 




exten => 98765, 


n, 


action_nouvel le 




exten => 98765, 


n, 


action_2 




exten => 98765, 


n, 


action_3 





Comme nous le constatons, il n'est pas necessaire de modifier les regies suivant l'ajout 
d'une nouvelle action. L'enchainement des regies est gere automatiquement. 

Enfin, I'application 

L'application deflnit Taction a entreprendre pour appliquer le service sollicite par l'utili- 
sateur appelant. Le serveur Asterisk dispose d'un grand nombre de procedures determinant 
le comportement a adopter, c'est-a-dire la maniere de traiter les flux audio. 

Le tableau 12.5 decrit quelques applications classiques. 

Tableau 12.5 - Applications les plus courantes 

Application Description 

Answer Repond a un appel telephonique entrant. 

Background Lit un message audio de maniere non bloquante. Autrement dit, une saisie d'une ou plusieurs touches 

par I'appelant est possible en parallele. Dans ce cas, la lecture du message audio en cours est inter- 
rompue. L'extension correspondant aux touches saisies par I'appelant est automatiquement appelee . 
Cela permet notamment de presenter une information facultative, comme une publicite ou un menu, 
que I'appelant peut interrompre des qu'il a pris connaissance de I'option qui I'interesse. 

Dial Met en relation I'appelant et I'utilisateur ou le service specifie en argument de l'application Dial. Cette 

commande est done utilisee pour affecter un numero de telephone a un utilisateur, a un terminal ou a 
un service. 

En argument de l'application, il faut indiquer le nom du compte a contacter, prefixe par le protocole de 
signalisation que le compte utilise (IAX2, SIP, etc.). Cela permet au serveur Asterisk de determiner 
dans quel fichier de configuration se trouvent les proprietes du compte appele (iax.conf, sip.conf, 
etc.). Nous verrons cela un peu plus loin, dans l'exemple 1 . 

II est possible d'appeler plusieurs correspondants en meme temps en mettant leur extension respective en 
arguments de l'application Dial, separes par le caractere & (esperluette). Par exemple : Dial (SIP/1001 & 
SIP/1005) fait sonner les postes affectes aux comptes 1001 et 1002 en meme temps. 
II est aussi possible d'ajouter un argument a l'application mentionnant la duree pendant laquelle la 
tentative d'appel doit s'effectuer. Par exemple : dial (SIP/identifiant, 30 ) permet de faire sonner le tele- 
phone de I'identifiant pendant une duree de 30 secondes. 



Pratique de la TolP 



Parte II 



Tableau 12.5 - Applications les plus courantes 



Application 


Description 


Echo 


Retourne I'echo de ce que I'appelant prononce. Cette application est utile notamment pour tester que 
les composants audio de reception et d'emission du son sont f onctionnels. 


Goto 


Branchement inconditionnel vers un contexte, une extension et une priorite particuliers. 


Gotolf 


Branchement conditionnel vers un contexte, une extension et une priorite particuliers lorsqu'une 
condition est verifiee. 


GotolfTime 


Branchement conditionnel vers un contexte, une extension et une priorite particuliers lorsqu'une 
condition temporelle est verifiee. 


Hangup 


Termine une communication. 


Meetme 


Invite un utilisateur a participer a une conference identified en argument de I'application Meetme. 


Playback 


Lit un message audio de maniere bloquante : la lecture du message doit se faire integralement, et 
I'appelant ne peut interrompre cette diffusion par une saisie de touche sur le clavier telephonique. 


Queue 


Met en attente une communication. 


Read 


Lit une variable. L'appelant est invite a entrer une valeur qui est sauvegardee sous forme de variable 
par le systeme. Cela permet notamment de demander un mot de passe a I'utilisateur avant d'acceder 
a un service specifique. 


Record 


Enregistre une communication dans un fichier son. 


ResponseTimeout 


Specifie en argument un delai au bout duquel I'attente du serveur expire. 


SayAlpha 


Annonce vocale de caracteres textuels specifies en argument de I'application 


SayDigits 


Annonce vocale de chiffres specifies en argument de I'application 


SayNumber 


Annonce vocale de nombres specifies en argument de I'application 


SayPhonetic 


Annonce vocale d'un message phonetique specifie en argument de I'application 


SayUnixTime 


Annonce vocale de I'heure, selon differents formats 


SendText 


Envoie un message textuel a I'utilisateur. 


SMS 


Envoi et reception de messages instantanes SMS 


System 


Execute une commande systeme du systeme d'exploitation. 


Transfer 


Transfere I'appel vers un autre poste ou service. 


VoiceMail 


Laisse un message vocal. 


VoiceMailMain 


Accede au systeme de messagerie vocale. 


Wait 


Attend pendant un certain delai specifie en argument. 


WaitExten 


Attend une saisie d'une extension par I'utilisateur. 



Ces applications peuvent prendre aucun ou plusieurs arguments donnes a la suite du nom 
de I'application. Lorsque plus d'un argument doit etre fourni a une application, les argu- 
ments se succedent avec un caractere de separation qui peut etre indifferemment une 
virgule ou un pipe (I). Les deux formes suivantes sont done equivalentes : 



Mon_appl ication (argumentl , argument^) 
Mon_appl i cation (argumentl | argument2) 
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Les extraits de plan de numerotation suivants illustrent quelques exemples simples, en les 
commentant. On suppose que les regies suivantes s'appliquent dans le contexte courant ; 
nous verrons plus loin comment basculer sur un contexte particulier. 

Exemple 1 

Voici un exemple important dans lequel nous allons affecter un numero de telephone a 
des utilisateurs (ou a des terminaux). 

La partie precedente nous avait permis de declarer des comptes d' utilisateurs (ou des 
terminaux). Nous avions ainsi ete amenes a definir deux comptes SIP (dont les identi- 
flants etaient david et laurent) et un compte IAX (dont l'identiflant etait 1231). Voici 
comment effectuer les affectations des numeros attribues aux utilisateurs avec leur 
compte respectifs. 




Si un appelant compose le numero 5551, il sera mis en relation avec l'utilisateur SIP 
(dont la definition doit imperativement avoir ete faite dans le flchier sip.conf), qui a pour 
identifiant david. II en va de meme pour l'identiflant laurent, avec le numero 5552, et 
pour le numero 1234, qui est lie au compte 1234, lequel utilise le protocole de signali- 
sation 1AX2 (le compte doit etre defini dans le flchier iax.conf). 

Exemple 2 

En composant le numero 54321, les regies suivantes sont enclenchees. 




Lorsque l'appelant compose l'extension 54321, les etapes suivantes sont lancees : 

1 . Accepte 1' appel et y repond. 

2. Renvoie en echo tout ce que dit l'appelant. L'echo se termine lorsque l'appelant saisit 
la touche diese. 

3. Diffuse un message audio intitule vm- goodbye fourni par defaut pour dire au revoir a 
l'appelant. 

4. Met final' appel. 
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Exemple 3 

En appelant un numero de telephone predefini, nous souhaitons que le serveur Asterisk 
nous retourne l'heure en cours. II s'agit en quelque sorte d'une horloge parlante. Les 
commandes suivantes permettre de fournir ce service : 



exten => 777, 


1, 


Answer 




exten => 777, 


2, 


SayUnixTime( 


.CET.kM) 


exten => 777, 


3, 


Hangup 





La premiere ligne accepte l'appel sur le numero 777, et la derniere le termine. L'application 
SayUnixTime donne l'heure en cours par un message vocal. 



Tester la configuration d'un client 

Les equipements des utilisateurs peuvent etre divers : telephone IP, PDA ou ordinateur. 
Nous allons utiliser dans cette section une solution generique de telephonie SIP, avec le 
logiciel grand public gratuit X-Lite. 

Simple d' utilisation, ce freeware est disponible en telechargement (en anglais unique- 
ment pour le moment), sur le site de l'editeur CounterPath (anciennement XTEN), a 
l'adresse http://www.counterpath.com/index.php?menu=download. 

La figure 12.3 illustre l'interface du logiciel. Parmi les autres clients SIP performants, 
signalons les logiciels SJPhone et LinPhone. 



Figure 12.3 

Le logiciel client X-Lite 
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Pour configurer le client X-Lite, un simple clic droit n'importe ou dans l'interface ouvre 
un menu contextuel permettant d'acceder au menu « SIP Account Settings ». 
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Dans la fenetre qui s'ouvre, il suffit de renseigner les champs illustres a la figure 12.4 : 

• identifiant affiche pour l'utilisateur (Display Name), pouvant etre forme de caracteres 
alphanumeriques ; 

• identifiant servant a loguer l'utilisateur (User Name) ; 

• mot de passe associe (Password) ; 

• nom sous lequel 1' autorisation d'acces est possible (Authorization user name) ; 

• nom de domaine (Domain) ; 

• adresse du serveur proxy (Proxy Address), c'est-a-dire le serveur Asterisk lui-meme 
(dans notre cas asterisk_srv). 

II est possible d'indiquer son nom si celui-ci est resolu par un serveur DNS en local ou, a 
defaut, d'utiliser 1' adresse IP du serveur Asterisk. 

Pour que l'authentification soit possible, ces valeurs doivent etre conformes a celles 
saisies dans le fichier sip.conf du serveur Asterisk. 



Figure 12.4 

Configuration de X-Lite 
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Une fois la configuration achevee, il faut valider ces parametres en cliquant sur le bouton 
OK, non sans avoir pris soin de verifier que la case « Enabled » est cochee pour le 
compte SIP que Ton vient de creer. Le bouton Close permet de fermer l'interface de 
gestion des comptes SIP. Le logiciel s'authentifie alors automatiquement aupres du 
serveur Asterisk mentionne. 
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Si cette etape s'effectue avec succes, un message « ready » s'afflche, indiquant que les 
communications sont desormais possibles. A defaut, un message d'erreur explique le 
motif qui a fait echouer le processus. Dans ce cas, il convient de verifier la validite des 
parametres du compte SIP (nom et mot de passe conformes au flchier sip.conf) et 1' exac- 
titude de l'adresse IP du serveur Asterisk. Verifier au besoin qu'un pare-feu ne bloque 
pas les communications SIP entre le client et le serveur. 

Optimiser les traitements 

La section [globals] du flchier extensions.conf permet de definir des variables, comme 
dans un langage de programmation. 

La syntaxe pour definir une variable est la suivante : 

Nom_de_variable => Valeur_de_variable 

L'exemple suivant deflnit les variables Numero_de_Guy et MusiqueAttente respectivement 
initialisees par les valeurs 4321 et /fichier_sons/son_opera.gsm : 



[globals] 














Numero_de_Guy = 


=> 


4321 










MusiqueAttente 




=> /fie 


hier_ 


_sons/son_ 


_opera 


.gsm 



Comme nous le constatons, les variables peuvent contenir des valeurs de nature diffe- 
rente, numeriques ou textuelles, ou encore des chemins d' arborescence. 

Pour utiliser ces variables, il sufflt de reprendre leur nom, encadre d' accolades et prefixe 
par le caractere $ (dollar). En indiquant ${Numero_de_Guy} dans le plan de numerota- 
tion, e'est la valeur 4321 qui est placee pour cette variable. Si, ulterieurement, le numero 
du poste de l'utilisateur Guy change, il sufflt de remplacer l'unique ligne initialisant la 
valeur de la variable Numero_de_Guy a la nouvelle valeur. Elle est aussitot prise en 
compte dans le plan de numerotation sans autre changement. 

II existe des variables speciales, qui sont preconflgurees par le serveur Asterisk. II est 
indispensable de respecter les majuscules et les minuscules dans l'ecriture de ces variables. 
Par exemple : 

• EXTEN represente l'identiflant d' extension courante. 

• CALLERID(all) represente le nom et le numero de 1' appelant. 

• CALLERID(name) represente seulement le nom de 1' appelant. 

• CALLERID(num) represente seulement le numero de 1' appelant. 
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• DIALEDTIME represente la duree de l'appel courant. 

• DATETIME represente la date courante (son usage est deprecie). 

• DIALSTATUS represente l'etat de l'appel en cours. 

La directive d'inclusion 

Si un flchier est trop volumineux et perd en lisibilite, il est possible de le scinder en 
plusieurs flchiers. II sufflt pour cela d'utiliser la directive include, comme dans les exemples 
suivants. 

Cas 1 : sans inclusion de flchier (un seul flchier) : 

fichier_l : ligne_l 

1 igne_2 
1 igne_3 
1 igne_4 
1 igne_5 

Cas 2 : avec inclusion de flchier (deux flchiers) : 



fichier_l : 


#in elude fichier_2 
1 igne_4 
1 igne_5 




fichier_2 : 


1 igne_l 
1 igne_2 






1 igne_3 





Dans ces exemples, les deux cas sont parfaitement identiques, si ce n'est que le code a ete 
segmente en deux parties dans le second. La directive optimise la qualite du code en 
evitant la redondance de code ou en allegeant les flchiers longs. 

Logique de programmation 

Parmi les applications disponibles dans la definition du plan de numerotation, on 
retrouve les classiques procedures de programmation de branchements (ou sauts) condi- 
tionnels et inconditionnels. Les applications Goto() et GotoIfO implemented ainsi 
respectivement un branchement inconditionnel et un saut conditionnel. 

L' application Goto prend comme argument un label speciflant ou doit s'effectuer le bran- 
chement. Un label peut etre deflni exhaustivement par la fourniture de trois elements : un 
contexte, une extension et une priorite. II n'est toutefois pas indispensable de specifier le 
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contexte et l'extension. Par defaut, si aucun contexte n'est donne, c'est le contexte 
courant qui est considere. De meme, si aucune extension n'est fournie, c'est l'extension 
par defaut qui est prise en compte. La mention de la priorite est le seul element obliga- 
toire. 

Voici un exemple d' application Goto : 



[mon_c 


innonce] 






exten 


=> s, 


1, 


PI ayback(msg_indication) 




exten 


=> s, 


2, 


ResponseTimeout (5) 




exten 


=> s, 


3, 


WaitExten 




exten 


=> #. 


1, 


Goto(mon_service, s, 1) 




exten 


=> *, 


1, 


Goto(mon_menu_principal , < 


5, 1) 


exten 


=> 1. 


1, 


Goto(s, 1) 




exten 


=> t. 


1, 


PI ayback(msg_au_revoi r) 




exten 


=> t. 


2, 


Hangup 




[mon_; 


service] 






exten 


=> s, 


1, 






[mon_menu_p 


rincipal ] 





Nous considerons que la communication est geree par le contexte [mon_annonce]. Le 
serveur reagit en fonction de la saisie de l'utilisateur. 

La premiere extension, s (pour start), est toujours activee par defaut. La premiere etape 
consiste en la diffusion d'un message audio nomme msg Judication (qui n'existe pas par 
defaut), indiquant a 1' appelant que ce dernier doit saisir une touche au clavier. La ligne 
suivante limite l'attente de cette saisie a 5 secondes. La troisieme etape de l'extension s 
enclenche l'attente de la saisie. 

Les quatre cas suivants peuvent se produire : 

• Si l'utilisateur saisit la touche diese, il est oriente (par 1' application Goto) vers le 
contexte [mon_service] (premier argument de l'application Goto) a l'extension s 
(deuxieme argument de l'application Goto) et sur 1' etape numero 1 (troisieme argu- 
ment de l'application Goto). La ligne sur laquelle le branchement doit s'effectuer est 
partiellement mentionnee plus bas, sans etre implementee : elle succede a la ligne 
[mon_service]. C'est la que figure la prochaine regie examinee pour le traitement 
correspondant a la saisie de la touche diese. 
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• Si l'utilisateur saisit la touche etoile, le traitement se poursuit sur la premiere etape de 
1' extension s du contexte [mon_menujprincipal] (egalement mentionne plus bas). 

• Si l'utilisateur saisit une autre touche que diese ou etoile, la procedure reprend depuis 
l'etape precedente, c'est-a-dire a la premiere etape de l'extension s du contexte 
[mon_annonce] (correspondant au contexte courant, qu'il n'est done pas necessaire de 
preciser). L'annonce l'invitant a saisir une touche est a nouveau diffusee, et le systeme 
se place en attente de cette saisie. 

• Si le delai imparti est ecoule, un message msg_au_revoir (n'existant pas par defaut) est 
diffuse a 1' appelant pour lui signifier qu'aucun signal n'a ete regu. La communication 
s'arrete. 

L' application Gotolf permet d'effectuer un branchement conditionnel. En argument de la 
fonction, il sufflt de mentionner la condition a realiser, suivie d'un point d' interrogation 
puis du label designant le branchement effectue si la condition est veriflee, et de terminer 
par le caractere deux-points suivi du label designant le branchement qui sera effectue si 
la condition n'est pas veriflee. 

II est possible d'omettre l'un des deux labels et de designer simplement le branchement 
dans le cas ou la condition est (ou n'est pas) realisee. II n'est pas possible d'omettre les 
deux labels simultanement. 



Voici un exemple d' application Gotolf: 



exten => 7979, l.Read (var_secret, rc-code, 


4) 




exten => 7979, 2, Gotolf ($[${var secret} = 


1234] ? code_valide,s,l 


code_i rival ide 


s, 1) 






[code_valide] 






[code_i rival ide] 







Ce code specifle pour l'extension 7979 la lecture d'une variable var_secret, qui est solli- 
citee par un message vocal nomme rc-code de 4 chiffres (1' absence de la valeur 4 en 
argument entrainerait l'acceptation d'autant de chiffres que l'utilisateur le souhaite, la 
sequence etant terminee et validee par l'appui sur la touche diese). 

Dans la deuxieme etape de cette extension, la valeur de la variable saisie par l'utilisateur 
est comparee a la valeur 1234. Si l'utilisateur a effectivement saisi cette valeur, la 
prochaine etape examinee est l'etape 1 de l'extension s du contexte [code_valide]. Si ce 
n'est pas le cas, on passe a la priorite numerotee 1 de l'extension s du contexte 
[code_invalide]. 
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Optimisation du routage avec les contextes 

Les contextes permettent de definir des cadres pour des procedures plus evoluees, 
ciblees, et controlees. Lorsque le code d'un plan de numerotation est segmente en 
contexte, il gagne en lisibilite, ce qui simplifie son suivi et sa mise a jour, au contraire 
d'un code compactant toutes les possibilites avant un seul contexte. 

Les contextes sont au plan de numerotation ce que les fonctions sont a la programmation. 
lis permettent de factoriser les actions a entreprendre, facilitant d'autant la reutilisation 
du code. Surtout, le code devenant modulaire, les traitements afferents a une extension 
particuliere, a des categories d'utilisateurs, a des services particuliers ou a des conditions 
specifiques peuvent etre regroupes dans une meme portion de code, qu'il est plus simple 
de maintenir ulterieurement. 

L'exemple de code suivant : 



[internal ] 








exten 


=> 801. 


1. 


Answer( ) 




exten 


=> 801. 


2. 


EchoO 




exten 


=> 801. 


3. 


Playback(vm 


-goodbye) 


exten 


=> 801. 


4. 


Hangup( ) 





peut etre remplace par le suivant : 

[internal] 

exten => 801, 1, Goto (mon_echo, s, 1) 

[mon_echo] 

exten => s, 1, Answer () 

exten => s, n, Echo ( ) 

exten => s, n, Playback (vm-goodbye) 

exten => s. n, Hangup ( ) 

Le second est certes plus long, mais il gagne en clarte, en particulier dans un plan de nume- 
rotation de plusieurs centaines de lignes. II est en outre reutilisable pour d'autres appels. 

Et la video ? 

Avec Asterisk, les sessions peuvent gerer des communications a la fois audio et video. 

Pour cela, et en supposant que les intervenants effectuent une communication en utilisant 
le protocole de signalisation SIP, il n'y a qu'une manipulation mineure a faire dans la 
configuration d' Asterisk. 
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La modification est a realiser dans le fichier de configuration sip.conf (qui se trouve, par 
defaut, dans le repertoire /etc/asterisk), en decommentant la ligne suivante (c'est-a-dire 
en retirant les points-virgules qui precedent cette ligne) : 

I 1 

videosupport=yes 

Des lors, les intervenants peuvent utiliser le logiciel SIP de leur choix et initier des 
communications qui couplent la video a la voix. 



Ajouter des sons 



Lors de la mise en place d'un serveur vocal, il peut etre necessaire de diffuser a l'appe- 
lant un message audio, par exemple, pour indiquer a un utilisateur le nombre de messages 
deposes sur son repondeur, lui presenter une liste de choix, lui demander de saisir un 
code d'authentification, ou lui transmettre une annonce informative. 

Asterisk offre divers fichiers audio en anglais, espagnol et fran^ais synthetisant differents 
messages generiques. II est possible d'etendre ces fichiers en ajoutant des sons de son 
choix. 

Synthese vocale 

Le paquetage asterisk-core-sounds-fr (telechargeable a l'adresse ftp://ftp.digium.com/pub/ 
telephony/sounds/) propose plusieurs centaines de fichiers audio en fran^ais utilisables avec 
Asterisk. 

Ces messages generiques de quelques secondes sont de bonne qualite. Differents formats 
de codage sont disponibles (G.711, G.722, G.729, gsm, wav). Le nom complet du fichier 
a telecharger comporte cette information a la suite du nom du paquetage. Par exemple, en 
telechargeant le fichier asterisk-core-sounds-fr-gsm-1.4.3.tar, nous obtenons un paque- 
tage au format GSM, dans sa version 1.4.3. Une fois decompresses a l'aide de la 
commande tar, les fichiers doivent etre places dans /var/lib/asterisk/sounds. 

Pour jouer ces fichiers audio a un appelant, il suffit de lancer la commande Playback en 
mentionnant en argument le nom du fichier a jouer, sans l'extension. 

En voici un exemple : 




Si 1' appelant compose le numero d'appel 123, le fichier audio hello-word.gsm est lu et le 
message audio « salut tout le monde » est diffuse. La communication est ensuite imme- 
diatement coupee. 
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Un autre cas de figure concerne les nombres. Si le serveur vocal doit renvoyer le nombre 
de messages re^us ou un temps d'attente ou encore un numero de telephone, il n'est pas 
envisageable de faire flgurer tous les nombres preenregistres possibles. Une synthese 
vocale est disponible par le biais des fonctions SayDigits() et SayNumber(). La premiere 
permet de prononcer et distinguer chaque chiffre entier composant un nombre. La 
seconde prononce le nombre directement (ce nombre doit etre compris entre et 
99 999 999). Par exemple, la commande SayDigits(123) synthetise le message audio « un 
deux trois », tandis que la commande SayNumber(123) synthetise le message audio « cent 
vingt-trois ». 

Enregistrer ses propres messages 

Asterisk offre la possibilite d'enrichir sa base de fichiers audio en l'utilisant comme un 
magnetophone. Cette fonction est tres pratique pour realiser des annonces specifiques. 
II sufflt pour cela d'utiliser la commande Record prenant en parametres un chemin 
(emplacement du fichier dans le systeme) associe a un format de flchier. 

La syntaxe de cette commande est la suivante : 

Record (chemin_d'enregistrement:format_de_sauvegarde| temps_son_blanc) 

Le parametre chemin_d' enregistrement designe l'emplacement dans l'arborescence du 
systeme ou le son doit etre enregistre. Pour etre exploitable par la suite par son nom et 
pas par son emplacement complet, le flchier doit etre place dans le repertoire sounds 
d' Asterisk. 

Le parametre format _de_sauvegarde precise le codec utilise. Le parametre 
temps _son_blanc permet d'ajouter un delai additionnel de bruit blanc a la suite du 
message. L'ajout d'un bruit blanc a un message audio permet a l'appelant d'effectuer ses 
choix et saisies. Par exemple, si nous souhaitons inviter l'utilisateur a saisir une succes- 
sion de touches au clavier, il faut lui laisser un temps ni trop court (pour qu'il ait le temps 
de saisir toutes les touches necessaires), ni trop long (pour ne pas l'impatienter et lui 
redonner des directives s'il n'est pas sufflsamment reactif). 

Ce temps predefini est donne en secondes. 

En voici un exemple : 
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Lorsque l'utilisateur compose le numero 456, un message audio lui joue le message 
« Vous pouvez parler maintenant ». L'enregistrement du son debute alors dans le fichier / 
tmp/rec, en utilisant le codec GSM. Sept secondes de son blanc y sont ajoutees. Ensuite, 
le message audio enregistre est rejoue a 1' appelant en echo, suivi d'un message echo- 
done, qui indique que l'appel d'echo est termine, avant de raccrocher. 

Cet exemple constitue un bon test pour valider a n'importe quel moment le fonctionne- 
ment de son equipement audio. C'est du reste une fonction disponible dans des logiciels 
tels que Skype (en appelant 1'identiflant echol23) ou Wengo (numero d'appel 333). 

Utiliser d'autres sons 

II est possible d'utiliser n'importe quel son dans Asterisk, a la condition qu'il respecte les 
formats de codage supportes. Si ce n'est pas le cas, plusieurs programmes permettent de 
convertir differents formats non pris en charge par Asterisk en des formats supportes. 

C'est le cas notamment du programme SOX, en licence GPL, telechargeable a l'adresse 
http://sox.sourceforge.net. Apres 1' avoir installe, il suffit, par exemple, d'effectuer la conver- 
sion d'un fichier au format MP3, nomme test.mp3, en un fichier au format GSM nomme 
test.gsm, avec la commande suivante : 

sox test.mp3 -r 8000 -cl test.gsm resample -ql 

Problemes eventuels avec les modules 

Situes dans le dossier /usr/lib/asterisk/modules, les modules peuvent etre parametres au 
moyen du fichier /etc/asterisk/modules.conf. 

Par defaut, le parametre autoload-yes, defini dans le fichier modules.conf, implique le 
chargement de tous les modules figurant dans le dossier modules d' Asterisk. Certains 
modules pouvant poser probleme, il est possible de changer ce mode et de desactiver les 
modules au demarrage, en specifiant la valeur no au parametre autoload. Dans ce cas, 
seuls les modules explicitement mentionnes par la directive load sont charges. 

Inversement, il est possible d'activer tous les modules et d'interdire le lancement d'autres 
modules explicitement mentionnes. Le plus simple en ce cas est de les desactiver. Pour 
desactiver des modules en particulier, il suffit de conserver la valeur yes au parametre 
autoload et de saisir a la section [modules] du fichier modules.conf la directive noload 
suivie du module a desactiver. 

En voici un exemple : 

[modules] 

noload => cdr_pgsql .so 

noload => codec_lpcl0.so 
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Ajouter de nouveaux services 

Notre plate-forme Asterisk etant desormais pleinement operationnelle, nous pouvons 
mettre en relation tous les utilisateurs entre eux. 

Cependant, aucun service evolue n'ayant encore ete configure, nous allons voir comment 
installer sur le serveur quelques services classiques. 

Standard vocal automatique (IVR) 

II est possible d'installer un IVR (Integrated Voice Responder), ou standard vocal auto- 
matique, permettant a 1' appelant de selectionner lui-meme la personne ou le service avec 
lequel il souhaite entrer en communication. 

Le standard automatique propose des menus a choix multiples conduisant a diverses 
actions speciflques, telles que des annonces informatives, le relais vers un service appro- 
prie, l'acces a des services de type repondeur ou la mise en relation avec un poste tele- 
phonique particulier. 

L'exemple suivant de standard vocal automatique est un cas d'ecole, puisque incomplet. 
Si l'utilisateur compose la touche etoile, il est invite a saisir le numero de poste tele- 
phonique qu'il souhaite contacter. Ce numero lui est repete avant la mise en commu- 
nication. Les erreurs et attentes sont egalement traitees. 



exten 


=> 


*, 1. 


Goto (menu_choix, s, 1) 


[menu_ 


.choix] 




exten 


=> 


s, 1, 


Background (enter-ext-of-person) 


exten 


=> 


1, 1, 


PI ayback(you-entered) 


exten 


=> 


1, 2, 


Playback(digits/1) 


exten 


=> 


1, 3, 


Dial (SIP/guy) 


exten 


=> 


1. 4, 


Hangup( ) 


exten 


=> 


2, 1, 


PI ay back (you -entered) 


exten 


=> 


2, 2, 


Playback(digits/2) 


exten 


=> 


2, 3, 


DiaKSIP/laurent) 


exten 


=> 


2, 4, 


HangupO 


exten 


=> 


1.1. 


Playback (pbx-inval id) 


exten 


=> 


i. 2, 


Goto (menu_choix, s, 1) 


exten 


=> 


t, 1. 


Hangup 
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La premiere ligne permet d'acceder au contexte [menu_choix] lors de la saisie de la 
touche etoile. Un message est alors diffuse pour demander a 1' appelant de choisir le 
numero de poste telephonique qu'il souhaite joindre. Nous traitons dans cet exemple 
deux postes, numerates 1 et 2. 

Les possibilites sont les suivantes : 

• L' appelant saisit la touche 1 (extension 7) : un message audio lui repete la touche qu'il 
vient de saisir, puis le systeme lance l'appel vers le poste numero 1, qui est attribue a 
l'utilisateur guy (en signalisation SIP). 

• L' appelant saisit la touche 2 (extension 2) : comme precedemment, apres la confirma- 
tion de la saisie, la communication vers le poste 2 attribue a l'utilisateur laurent est 
initiee (en signalisation SIP). 

• L' appelant saisit une autre touche que 1 ou 2 (extension/): un message audio 
l'informe de l'invalidite de la saisie, puis l'etape precedente est immediatement 
reactivee, l'invitant a saisir une nouvelle touche. 

• L' appelant ne saisit aucune touche pendant un delai determine (extension t) : l'appel se 
termine aussitot. 



Conference 



Deux etapes suffisent pour mettre en place une conference avec Asterisk : creer les salons 
de conference virtuelle et y inviter des participants. 

Creer des salons virtuels de conferences (fichier meetme.conf) 

Pour creer des salons de conferences, il suffit de configurer le fichier meetme.conf en 
ajoutant a la section [rooms] le code suivant : 



conf 


=> numero_de_conference 










[ 


, code_acces_simple ] 
[ , code_acces_administrateur ] 



Le mot-cle Conf correspond a une nouvelle salle de conference virtuelle, definie au mini- 
mum par 1' indication d'un numero de salle (numero _de ^conference). II peut etre 
complete optionnellement par un code d'acces que l'utilisateur devra fournir pour acce- 
der a la salle virtuelle et eventuellement d'un code d'acces permettant de reconnaitre 
l'administrateur, auquel des droits de gestion du salon virtuel sont attribues. 

Par exemple : 

conf => 770 
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permet de creer un salon ayant pour identiflant le numero 770. Nous pouvons le 
completer en rempla^ant la ligne precedente par : 

conf => 770, 12345, 150379 

Cela cree un salon d' identiflant 770, auquel les utilisateurs peuvent acceder en indiquant 
le code 12345 et dont l'administrateur s'identifie par le code 150379. 

Inviter des participants a la conference (application Meetme) 

Pour inviter des participants a entrer dans la salle de conference, il faut les aiguiller en 
utilisant le plan de numerotation et 1' application Meetme. 

Pour rediriger une communication vers la conference precedente, II sufflt d'utiliser 
l'appel Meetme (770) dans le flchier extensions.conf. 

Par exemple, si l'appelant compose le numero 770, l'extension suivante l'invite a rejoindre 
la conference 770 : 




exten => 770, 1, Meetme (770) 

II est possible d'ajouter en second argument de 1' application Meetme une ou plusieurs 
des options recapitulees au tableau 12.7 (s'il y en a plusieurs, les options sont indiquees 
en se succedant sans caractere de separation). 

Tableau 12.7 - Options de I'application Meetme 

Option Description 

m Active le mode monitor : les participants peuvent ecouter, mais pas parler. 

p Un participant peut quitter la conference en pressant la touche diese . 

t Active le mode talk : les participants peuvent parler, mais pas ecouter. 

v Active le mode video. 

q Mode silencieux (quiet) /aucun son n'est emis lorsque des utilisateurs entrent dans la conference 

ou en sortent. 

d Ajoute une conference dynamiquement. 

M Active une musique d'attente lorsqu'il n'y a qu'un seul participant a la conference. 

b Lance le script AG I specif ie dans la variable MEETME_AGI_BACKGROUND (celle-ci doit avoir 

ete initialised auparavant). 
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Le service de message rie audio (fichier voicemail.conf) 

Le service de messagerie audio se met en place tres simplement via la configuration de 
seulement trois flchiers : le premier permet de deflnir les parametres du compte de message- 
rie vocale, le deuxieme d'acceder a la boite vocale creee, et le troisieme de signaler a un 
utilisateur tout nouveau message vocal re^u. 

Le principe du service de messagerie audio consiste a deflnir un numero de boite vocale 
associe a un utilisateur. Cela permet notamment a un meme utilisateur d' avoir plusieurs 
numeros de telephone (professionnel, personnel, autre) et une seule messagerie uniflee, 
archivant les messages qui lui sont destines, que ces derniers soient personnels, profes- 
sionnels ou autres. 

Dans un cadre professionnel, il est aussi possible de permettre a plusieurs utilisateurs 
d' avoir un numero de telephone speciflque, tout en leur assignant une messagerie uniflee. 
Un message laisse sur le repondeur unique peut de la sorte etre traite par la premiere 
personne disponible dans le service. 

Les sections qui suivent montrent comment creer des boites vocales, les affecter a des 
utilisateurs et signaler la presence de nouveaux messages audio. 

Creer des comptes de messagerie audio (fichier VoiceMail.conf) 

La premiere etape consiste a creer les boites vocales. Le fichier VoiceMail.conf 
comporte a cet effet deux sections distinctes : [general], qui permet de parameter les 
options des comptes, et [default], qui decrit les comptes a creer. 

En voici un exemple : 

[general] 

format=gsm 

attach=yes 

fromstring=Ma Messagerie Vocale 

[default] 

3535 => 15155, guyjaurent, guy_laurent@fai_home.fr 

La section [general] permet de deflnir differents parametres de configuration, notamment 
les suivants : 

• format: deflnit le format d'encodage des messages audio enregistres (par defaut 
wav49, gsm et wav). 

• maxmessage : specifle la duree maximale (en secondes) d'un message. La valeur par 
defaut est 0, signiflant qu'il n'y a pas de duree maximale. 

• minmessage : specifle la duree minimale (en secondes) d'un message. La valeur par 
defaut est 0, signiflant qu'il n'y a pas de duree minimale. 
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• maxmsg : specifie le nombre maximal de messages qui peuvent etre laisses sur la boite 
vocale. La valeur par defaut est 100. 

• review : autorise 1' appelant a ecouter et modifier le message laisse. La valeur par 
defaut est no. 

• attach : indique si les messages vocaux laisses sur une messagerie sont egalement 
envoyes par e-mail aux utilisateurs concernes. La valeur par defaut est no. 

• maxlogins : indique le nombre maximal de tentatives d'acces infructueuses autorise. 

• emailsubject : mentionne le sujet de l'e-mail notiflant le message vocal. 

• mailcmd : indique chemin de la commande utilisee pour 1' envoi des e-mails. La valeur 
par defaut est usr/sbin/sendmail -t. 

• fromstring : specifie un nom avec lequel l'e-mail notiflant le message vocal est envoye. 
La valeur par defaut est Asterisk PBX. 

• emailbody : indique le contenu de l'e-mail signalant la reception de nouveaux 
messages vocaux. II est possible d'utiliser des variables dans la definition de ce para- 
metre. 

Dans l'exemple suivant, le nom de l'utilisateur et le nombre de messages sont automa- 
tiquement remplaces par les variables correspondantes : 

emailbody=Bonjour ${VM_NAME}, vous avez ${VM_MSGNUM} message(s) dans votre boite 
vocale. 

Dans notre exemple, apres la section [general], la section [default] specifie les comptes 
a creer et leurs proprietes. Nous avons cree une seule boite vocale identiflee par le 
numero 3535. Son mot de passe, 15155, permet a son possesseur d'acceder a sa message- 
rie. Cette derniere est affectee a l'utilisateur guyjaurent ayant pour adresse de messagerie 
guy _laurent@rnonJai.fr (c'est a cette adresse que seront envoyes les messages vocaux 
laisses sur la messagerie de l'utilisateur si le parametre attach defini precedemment est 
active a la valeur yes). 

Laisser un message et ecouter ses messages (applications VoiceMail 
et VoiceMailMain) 

Nous considerons ici deux cas de figure, selon qu'un utilisateur souhaite laisser un 
message sur la boite vocale d'un autre utilisateur ou consulter ses propres messages sur 
sa propre boite vocale. 

Acceder a la boite vocale d'un correspondant 

Dans le premier cas, sans reponse de l'appele au bout d'un certain temps, il faut 
enclencher une procedure effectuant le basculement de l'appel vers la messagerie du 
correspondant. 
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La fonction a utiliser pour cela est VoiceMail, qui prend comme argument le numero de 
la boite vocale, ainsi que, optionnellement, le contexte associe. Cet argument est donne 
sous la forme numero_de_boite_vocale@contexte_associe, par exemple : 



Voicemail(1000@default) 

Dans 1' exemple suivant insere dans le plan de numerotation (flchier extensions.conf), 
l'appel est initie vers l'utilisateur guyjaurent en composant le numero 1235. Au bout de 
50 secondes sans reponse, la messagerie affectee a guyjiaurent et identiflee par le 
numero de boite vocale 3535 est enclenchee : 




La fonction VoiceMail prend en charge le service de repondeur en invitant 1' appelant a 
parler et en enregistrant le message. Ce dernier est accessible par l'appele en consultant 
sa boite vocale. 

Consulter sa boite vocale 

Pour gerer la consultation des messages, il suffit de mettre en place un numero d'appel 
specialement dedie a la consultation de la messagerie. La fonction VoiceMailMain 
permet de lancer la messagerie souhaitee. Comme la fonction VoiceMail, elle prend pour 
argument le numero de boite vocale et optionnellement le contexte associe. 

Dans l'exemple suivant, en composant l'extension 800, l'appel est directement redi- 
rige vers la consultation de la messagerie correspondant a la boite vocale identiflee 
par le numero 3535 (correspondant au compte de messagerie vocale de l'utilisateur 
guyjiaurent) : 




La fonction VoiceMailMain prend en charge le service de consultation en demandant 
notamment le mot de passe de l'utilisateur, puis en lan^ant la lecture, la suppression et 
plus generalement la gestion des messages audio. 

Cette implementation peut etre optimisee. Par exemple, au lieu d'affecter le numero 
d'appel 800 exclusivement a la boite vocale de l'utilisateur guyjaurent, il serait prefera- 
ble, comme cela se fait couramment en telephonie classique, de disposer d'un numero 
d'appel unique pour gerer la messagerie de tous les abonnes et d' utiliser une identification et 
authentication pour acceder a la boite vocale desiree. 
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Signaler la presence d'un nouveau message audio 

Pour signaler aux utilisateurs la presence d'un nouveau message audio dans leur boite 
vocale, il sufflt d'associer cette derniere au compte d'un utilisateur. Par exemple, si un 
utilisateur utilise le protocole de signalisation SIP, son compte est cree dans le flchier 
sip.conf, et il sufflt d'ajouter a la section [guy_laurent] de ce compte la ligne 
suivante : 

mailbox=3535@default 



Aller plus loin avec Asterisk 

Les possibilites d' exploitation du serveur Asterisk sont telles que le logiciel n'a pas a 
rougir de la comparaison avec ses equivalents PBX traditionnels, souvent hors de prix et 
de portee des particuliers. 

Dans ce chapitre, nous n'avons evoque qu'un fonctionnement standard, illustrant les 
usages les plus courants, mais quantite d'autres possibilites sont envisageables. On pour- 
rait presque dire que tout ce qu'un PBX physique traditionnel sait faire, Asterisk peut le 
faire aussi. 

Nous mentionnons dans cette section quelques autres fonctionnalites parmi les plus 
remarquables offertes par Asterisk. 

Connecter Asterisk a un fournisseur SIP 

II existe de nombreux acteurs qui proposent a leurs clients de communiquer en utili- 
sant le protocole de signalisation SIP. C'est le cas, par exemple des fournisseurs 
d'acces fran^ais Free et Neuf Telecom, mais aussi de la societe Wengo avec son logi- 
ciel WengoPhone dont nous avons deja parle dans un precedent chapitre, ou encore de 
VoIPDiscount, egalement evoque precedemment. Bien souvent, ces comptes sont 
associes a des conditions tarifaires tres avantageuses, notamment la gratuite des 
appels dans plusieurs dizaines de pays. Pourquoi ne pas faire proflter Asterisk de ce 
compte ? 

L'idee ici serait alors de disposer d'un compte SIP que nous procure l'une de ses societes, 
et de configurer Asterisk avec celui-ci. De cette maniere tous les telephones relies au 
serveur Asterisk pourront beneflcier des memes conditions tarifaire de leur compte SIP. 
Les avantages sont multiples : 

• Tous les telephones connectes a Asterisk peuvent tirer profit du compte SIP, meme s'ils 
ne sont pas compatibles SIP, puisque Asterisk sert de passerelle. 
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• Les services actives sur Asterisk restent disponibles dans le cadre des communications 
effectuees via le compte SIP (journalisation des appels, enregistrement du carnet 
d'adresses, etc.). 

• Les utilisateurs connectes n'ont pas a configurer leur logiciel avec le compte SIP (ils 
n'ont meme pas besoin de le connaitre). 

• Si le fournisseur SIP propose un numero d'appel entrant, il n'est pas necessaire d' avoir 
un logiciel SIP speciflque qui soit actif, ni meme un telephone de VoIP compatible SIP 
pour recevoir les communications : Asterisk pourra etre configure pour recevoir 
tous les appels entrants vers ce numero d'appel et les rediriger vers n'importe quel 
telephone. 

On considere dans la suite qu'on dispose d'un serveur Asterisk fonctionnel et d'un 
compte SIP (identiflant, mot de passe, adresse du serveur SIP a contacter et eventuelle- 
ment numero de telephone si le fournisseur SIP le propose). On ne doit s'assurer que Ton 
dispose des parametres SIP correctes (souvent, l'utilisateur dispose d'un compte aupres 
du fournisseur, qui n'a rien a voir avec son compte SIP, mais sert, par exemple, a la factu- 
ration de son compte sur Internet ou a d'autres fonctionnalites : c'est notamment le cas 
avec le logiciel WengoPhone ou les utilisateurs se connectent au logiciel avec des para- 
metres qui ne sont pas des parametres SIP). 

Nous allons mettre en ceuvre cette fonctionnalite, en realisant plusieurs etapes : d'abord 
on configurera le serveur Asterisk comme etant un client SIP, puis on declarera le compte 
SIP dont on dispose et enfln on redirigera les appels sortants vers le fournisseur SIP, et les 
appels entrants vers le telephone de son choix. 

Pour realiser la premiere etape, on ajoute une ligne dans le flchier sip.conf, a la section 
[general]. Cette ligne va permettre de s'enregistrer aupres du fournisseur SIP comme 
etant l'utilisateur, et comme etant actif dans le reseau (done pouvant appeler et recevoir 
des communications). Elle doit avoir le format suivant : 

register => identif i ant[ :mot_de_passe]@adresse_fournisseur_sip[ :port][/param] 

L' extension a saisir pour faire d' Asterisk un client est register. On lui associe trois infor- 
mations : le nom de l'utilisateur (identifiant), son mot de passe presque toujours obliga- 
toire (mot_de_passe), et on mentionne le nom (ou 1' adresse IP) du serveur SIP que le 
fournisseur SIP doit fournir (adresse_fournisseur_sip). Eventuellement on peut preciser 
un port specifique si le fournisseur SIP l'exige (port), et un parametre que le fournisseur 
SIP pourra interpreter. 

Un exemple d' utilisation est donne dans ce qui suit : 

i i 

register => david:d@vld@si p. voipdiscount.com 
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Dans un second temps, et toujours dans le fichier sip.conf, apres la section [global], on 
declare une section qui deflnira les proprietes du compte SIP : 

[nom_fournisseur_sip] 

type=peer 

username= i dent i fiant 

secret= mot_de_passe 

fromuser= i dent i fiant 

cal 1 erid=identi fiant <numero_tel> 

fromdomdi : \r]=adresse_fournisseur_sip 

host=adresse_fournisseur_sip 

nat=yes 

canreinvite=/7o 

context=appe ls_ent rants 



On retrouve essentiellement des memes elements deja presentes, et qu'il faut remplacer 
par les parametres du compte (ces parametres sont en italiques), avec, optionnel- 
lement, un numero de telephone {numero _tel) si le fournisseur SIP le propose. Les 
parametres nat et canreinvite sont egalement a adapter (selon qu'on se trouve effecti- 
vement derriere un nat ou non). L' intitule de la section est quelconque (ici 
nornJournisseur_siip). Le contexte nomme appels_entrants sera defini plus loin. 

Puis, dans la section [internal] du fichier extensions. conf, on ajoute une ligne pour rediri- 
ger les appels sortants (done que les utilisateurs d' Asterisk emettent) vers le serveur SIP 
du fournisseur : 

exten =>_0., 1, Dial (SIP/${EXTEN}@adresse_fournisseur_sip) 

L'identiflant d' extension « _0. » permet de flltrer tous les appels dont le numero 
commence par le chiffre 0. On remarque l'utilisation de la variable speciale EXTEN, qui 
correspond au numero de telephone saisi par 1' appelant. 

Enfln, et optionnellement, si le fournisseur SIP propose a ses clients un numero de tele- 
phone, alors toujours dans le fichier extensions. conf, on ajoute une section pour rediriger 
les appels entrants sur ce numero (qu'on notera comme precedemment numero_tel) vers 
le compte de son choix (ici le compte nom_compte, a remplacer par nom_compte) : 



[appels_entrants] 






exten => numero_tel , 


1, 


Answer 


exten => numero_tel , 


Z, 


Dial (SIP /nom_compte) 


exten => numero_tel , 


3, 


Hangup 
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Dans ce cas, lorsque des utilisateurs cherchent a joindre le numero nurnerojel, l'appel 
est automatiquement rediriger vers le compte nom_compte en utilisant le protocole de 
signalisation SIP (qui doit etre defini dans le fichier sip.conf). 

Bien sur, cette possibilite est a restreindre au seul cercle prive. Elle entrerait en violation 
avec les conditions d'utilisation du contrat si elle etait exploitee a des fins mercantiles, ou 
tout simplement en dehors du cercle prive. 

AGI (Asterisk Gateway Interface) 

Asterisk est un logiciel totalement ouvert, a la fois par ses sources, qui sont disponi- 
bles en telechargement et que les programmeurs peuvent enrichir et personnaliser au 
sein de la communaute, et par le developpement de logiciels tiers et 1' interaction avec 
eux. 

Les developpeurs d' Asterisk facilitent le travail des autres programmeurs en leur propo- 
sant une interface generique de controle et de gestion du serveur Asterisk, appelee AGI 
(Asterisk Gateway Interface). N'importe qui peut done developper une application, dans 
le langage de programmation de son choix, et la personnaliser a son gres afin d'interagir 
avec le serveur Asterisk. 

Peu de constructeurs offrent ce degre d'ouverture et de compatibility . Le plus souvent, 
les utilisateurs doivent se contenter de ce que leur proposent leurs equipementiers, car 
1' implementation logicielle, en plus d'etre fermee, est protegee dans son code source et 
n'offre generalement aucun systeme d'interface comparable a l'AGI. 



Trixbox 



Trixbox (anciennement Asterisk® home) est une distribution complete et libre du serveur 
Asterisk qui a la particularite d'etre accessible a partir d'un CD bootable. Elle peut etre 
telechargee sur la page de l'editeur, a l'adresse http://www.trixbox.org. 

Actuellement disponible uniquement en version anglaise, ce logiciel permet de se faire 
une idee d' Asterisk avant de 1' adopter et sans se lancer dans des procedures d' installation 
et de configuration. 

Par defaut, tout est prevu pour fonctionner au lancement. II est toutefois possible de 
modifier les configurations de base en suivant les indications fournies dans ce chapi- 
tre. Pour cela, il suffit d'arreter le serveur Asterisk puis de remplacer le contenu des 
fichiers du repertoire /etc/asterisk par ceux indiques aux sections precedentes de ce 
chapitre. 

Certains modules peuvent etre desactives s'ils sont inutiles ou qu'ils posent probleme 
(option noload dans le fichier modules.conf). 
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Communiquer avec le protocole IAX 

Le projet Asterisk a donne naissance a un second projet, appele IAX (Inter Asterisk 
eXchange). Celui-ci definit un protocole permettant 1' interconnexion entre serveurs 
Asterisk, mais egalement la communication entre un client et un serveur Asterisk. 

Initialement, le protocole IAX a ete developpe par le concepteur d' Asterisk, Mark Spen- 
cer, de la societe Digium. II est aujourd'hui maintenu par la societe Digium et est dispo- 
nible dans sa deuxieme version IAX2, laquelle fait l'objet d'une proposition de normali- 
sation a 1' IETF. 

Pour etre convaincante dans un contexte ou la concurrence entre les protocoles H.323 et SIP 
est deja importante, la philosophic proposee par IAX difrere sur deux points importants : 

• Traversee transparente des passerelles NAT et des pare-feu. Contrairement aux proto- 
coles SIP et H.323, qui n'assurent que la fonction de signalisation et se combinent 
generalement a RTP pour la fonctionnalite de transport des flux, le protocole IAX est 
a la fois un protocole de transport et un protocole de signalisation. Cela lui permet plus 
facilement de traverser les pare-feu et de supporter les translations d'adresses IP (NAT) 
dans un reseau. Ses flux n'utilisent qu'un port fixe et unique (le port 4569) et peuvent 
de la sorte etre aisement identifies. 

• Utilisation reduite de la bande passante. Si H.323 et SIP sont prevus pour le multi- 
media en general, IAX a ete con^u specifiquement pour le probleme du transport et de 
la signalisation de la voix, en ecartant les considerations plus generates des applica- 
tions multimedias. Le protocole IAX repond ainsi a des objectifs simples et bien deli- 
mites. Bien qu'il n'exclue pas a priori le traitement de flux video, il s'interesse avant 
tout aux flux audio et optimise les parametrages des flux en tenant compte des 
contraintes et des specificites de ces flux audio. 

IAX est un protocole puissant, qui propose des solutions efficaces aux deux problemes 
importants rencontres par H.323 et SIP et permet les communications entre serveurs 
Asterisk. II souffre toutefois de 1' inconvenient de ne pas etre normalise. De plus, il 
n' optimise que le traitement des flux telephoniques, alors que H.323 comme SIP sont 
plus generalistes et peuvent s'appliquer au transfert de la video. 

Asterisk sous Windows 

Une version du serveur Asterisk a ete developpee sous plate-forme Windows. Nommee 
asteriskwin32, elle est telechargeable a l'adresse www.asteriskwin32.com. Bien qu'elle soit 
beaucoup moins performante que le logiciel original sous Linux, cette solution constitue 
un excellent moyen de se familiariser avec les concepts generaux d' Asterisk. 

L'utilisateur dispose d'une interface conviviale lui permettant d'acceder a toutes les fonc- 
tionnalites du logiciel. On y trouve notamment une preconfiguration initiale du plan de 
numerotation, qui peut etre visualisee en selectionnant la fonction Dialplan du menu 
Commands. Comme sous Linux, la modification s'effectue en editant le fichier exten- 
sion.conf place dans le repertoire /etc/ du repertoire specifie lors de 1' installation du logiciel. 
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De meme, des comptes d'utilisateurs sont deja crees (SIP et IAX uniquement), et les 
principaux services sont preconfigures. Pour personnaliser ces services, nul besoin 
d'aller modifier des fichiers. II suffit d'utiliser l'interface, comme l'illustre la figure 12.5 
representant la configuration du service de messagerie telephonique. 



Figure 12.5 

Configuration du 
service de messagerie 
audio sous Windows 
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CLI> show dialplan 

[ Context 'default' created by 'pbx _config' ] 
'99990' => 1 . Answer!) 

2. AGI(agi-test.agi) 

3. Hangup() 
'99991 ' => 1 . AnswerQ 

2. EAGI(eagi-test) 

3. Hangupf) 
'99992' => 1 . Answer() 

2.Wait(1) 

3. SayUnixTimeQ 

4. Hangup() 
'99999' => 1 . AnswerQ 

2.Wait(1) 

3. MusicOnHoldf) 
Include => 'demo' 
Include => 'parkedcalls' 
Include => 'pstn' 
Include => 'internal' 
[ Context 'internal' created by 'pb 
'3000' => 1. Dial(SIP/300C 

2. Playback(invalid) 

3. Hangupf) 
102.Voicemail(u30( 



VoicehtaiL Settings 



Connected,., 



Smtp server jsnntp. server 



PBX Mail | asterisk 
SmtpAuthentification 

I 



Login 



Password 



1234 

3000 



3003 



Add 



Edit 



Delete 



Voice file 
W attach voice file 

Max.message length 


File format 






| wav49 _▼] 
Min. message length 


|180 


r^ 



User 


Mailbox |3001 


Name (Example Mailbox 


Password J4242 


Email |root@|ocalhost 


Pager 


Options 

Cancel Valid 





La concurrence 



Si Asterisk est le plus connu des PBX logiciel, il n'est pas le seul. Deux autres logiciels, 
egalement libres, Vocal et SIP-X, ont une vocation semblable a celle d' Asterisk. 



Vocal 

Developpe en 1999 par la societe Vovida, Vocal (Vovida Open Communication Applica- 
tion Library) est soutenu par d'importants industriels tels que Cisco, qui en a fait 1' acqui- 
sition en novembre 2000. 

Solution de telephonie complete et multiplate-forme (BSD, Linux, Windows, Solaris), 
Vocal inclut des interfaces d' administration du systeme, un serveur de politiques exploi- 
tant le protocole COPS (Common Open Policy Service) et un large choix de fonction- 
nalites telephoniques. 
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La communaute Vocal demeure cependant nettement moins active que celle d' Asterisk. 
Le produit lui-meme est moins abouti en termes d' integration avec les codecs et protocoles 
existants. 

Le site de l'editeur (http://www.vovida.org) permit d'obtenir davantage d' information sur ce 
PBX-IR 

SIP-X 

Parraine par la societe Pingtel, SIP-X est le dernier-ne des autocommutateurs libres. A la 
maniere de Digium pour Asterisk, Pingtel assure les services de maintenance et de mise 
a jour du logiciel. Plus generalement, les developpeurs sont regroupes au sein du groupe 
SIPFoundry. 

Pour fonctionner, SIP-X requiert l'utilisation de logiciels clients ou de terminaux compa- 
tibles SIP exclusivement. II n'est done pas aussi large d'utilisation qu'Asterisk. 

Plus d' informations peuvent etre trouvees sur le site de l'editeur, a l'adresse http:// 
www. sip foundry. org/sipX/index. htm. 



Conclusion 



Ouvert a tous, gratuit, simple a utiliser, puissant et performant, Asterisk a vraiment de 
quoi seduire, et meme rivaliser avec les equipements professionnels. En fait, les vrais 
concurrents d' Asterisk ne sont pas les autres PBX logiciels, mais les PBX hardware eux- 
memes. 

En effet, si les PBX hardware sont chers, ils demeurent performants et fiables. Surtout 
qu'ils disposent generalement d'un support technique appreciable. Au moindre 
probleme, un technicien peut intervenir dans des delais tres courts, ce qui rassure 
evidemment les entreprises, lesquelles ne sont pas toujours pretes a faire des economies 
s'il faut, pour cela, tenter le pari d'une solution ouverte. Ces solutions libres, en effet, 
peuvent fournir des outils performants et tres bien documentes, mais generalement sans 
procurer la garantie d'un service apres-vente, pourtant rassurante lorsqu'on exploite une 
infrastructure destinee a la telephonie sur IP. 

II faudra done certainement encore du temps avant qu'Asterisk gagne le meme statut que 
ces concurrents et dispose d'un capital de confiance aussi fort chez les professionnels. De 
nombreuses societes ceuvrent cependant dans ce sens et proposent d'ores et deja un 
service de bout en bout assurant la fourniture materielle et logicielle, ainsi que 1' installation 
et la maintenance du logiciel. 

Dans un secteur en pleine mutation, ou le monde RTC s' efface au fur et a mesure que le 
monde IP prend sa place, Asterisk influence d'ores et deja les strategies des equipementiers 
en montrant la voie. 
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La telephonie 
chez les fournisseurs d'acces 



Le haut debit a 1' acces est devenu une necessite dans un monde ou la quantite et la qualite 
des informations a transporter augmentent sans discontinuer. Un debit de l'ordre du 
megabit par seconde semble etre une valeur minimale pour realiser des acces dits a haut 
debit. Avec l'arrivee de la television et de sa version haute definition associee a plusieurs 
chaines de television simultanees, il faut pouvoir compter aujourd'hui sur une cinquantaine 
de megabits par seconde. 

Ce chapitre s'interesse aux acces haut debit terrestres pour les particuliers et les petites et 
moyennes entreprises, et plus precisement a 1'integration de la parole telephonique dans 
ces environnements. Ces acces comprennent quatre types : la ligne telephonique par le 
biais d'un modem xDSL, le cable CATV associe a un modem cable, la fibre optique et 
l'acces Wi-Fi en Quadruple-Play. 



Les acces xDSL 

Les modems xDSL permettent d'utiliser les paires metalliques du reseau d'acces pour 
realiser une boucle locale a haut debit. Le debit depend fortement de la qualite du cable 
utilise et de la distance a parcourir. Plusieurs categories de modems xDSL sont commer- 
cialisees, la lettre x permettant de les differencier. 

Les modems ADSL (Asymmetric Digital Subscriber Line) sont les plus repandus. Leurs 
vitesses sont dissymetriques, plus lentes entre le terminal et le reseau que dans 1' autre 
sens. En regie generale, le sens montant est quatre fois moins rapide que le sens descen- 
dant. Les vitesses sur le sens descendant peuvent atteindre 2 Mbit/s pour une distance de 
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l'ordre de 5 km et depasser la vingtaine de megabits par seconde lorsqu'on est a moins 
d'un kilometre de l'equipement de l'operateur. 

Le modem ADSL utilise une modulation d'amplitude quadratique, c'est-a-dire que 
16 bits sont transposes a chaque signal. Avec une rapidite de modulation de 340 kilo- 
bauds et une attenuation de l'ordre d'une trentaine de decibels, on atteint plus de 5 Mbit/s. 

Devant le succes rencontre par la technique ADSL, des derives en ont ete proposes, 
notamment la technique consistant a faire varier le debit sur le cable, qui a donne nais- 
sance au RADSL (Rate Adaptive DSL). Pour les hauts debits, les solutions HDSL (High 
bit rate DSL) et VDSL (Very high bit rate DSL) peuvent etre exploitees avec succes si le 
cablage, souvent en fibre optique, le permet. 

Les mesures effectuees chez les operateurs montrent que les debits deviennent de plus en 
plus symetriques depuis 1' apparition des applications peer-to-peer (P2P), les stations des 
utilisateurs client devenant des serveurs. Les techniques SDSL (Symmetric DSL) vont 
done devenir de plus en plus courantes chez les particuliers. Elles sont aujourd'hui reservees 
aux entreprises jusqu'a des valeurs de 8 Mbit/s. 



Le modem xDSL 



Deux techniques sont utilisees pour augmenter le debit sur une communication xDSL : le 
full-duplex, qui est assure sur une meme paire grace a l'annulation d'echo, et l'utilisation 
d'un code specifique (2B1Q). 

Les modems ADSL possedent une bande montante de 4 a 100 kHz, qui est utilisee pour 
des debits de 0,64 Mbit/s. La bande descendante est comprise entre 100 kHz et 1,1 MHz, 
qui permet d'atteindre le debit de 8,2 Mbit/s. La parole analogique, entre et 4 kHz, 
passe en parallele des donnees utilisant le modem. 

Les codes en ligne des modems ADSL reposent soit sur la modulation CAP (Carrierless 
Amplitude and Phase), soit sur la norme DMT (Discrete MultiTone), de 1' ANSI (American 
National Standards Institute) et de l'ETSI. La methode DMT consiste en l'utilisation de 
256 canaux de 4 kHz, chaque canal permettant remission de 15 bits par hertz au maximum. 

La figure 13.1 illustre la partie du spectre utilisee par les modems ADSL. 



Figure 13.1 
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Le spectre est decoupe en trois parties, une entre et 4 kHz pour faire passer la parole 
telephonique, qui continue a etre acheminee en parallele des donnees, une entre 4 et 
100 MHz pour la voie montante allant du terminal vers le reseau et une entre 100 kHz 
et 1,1 MHz pour la voie descendante allant du reseau au terminal. 

Des variantes peuvent exister en decoupant la bande de fa^on differente, par exemple 
entre 4 et 250 MHz pour la voie montante et entre 250 MHz et 1,1 MHz pour la voie 
descendante. La generation de modems ADSL2+ utilise une bande passante encore plus 
importante, permettant d'atteindre la frequence de 2,2 MHz et des debits associes de 
25 Mbit/s dans le sens descendant et 1,2 Mbit/s dans le sens montant. 

La partie montante du spectre de l'ADSL de base est divisee en 20 sous-bandes de 
4,3 kHz. Chaque sous-bande est capable de transporter de 4 a 15 bits en parallele. En 
choisissant 8 bits par intervalle d'horloge, avec 4 000 intervalles de temps par seconde, le 
modem ADSL permet de transporter : 

4 000 x 8 bits = 32 Kbit/s par sous-bande 

Comme il y a 20 sous-bandes, on arrive au total de 32 x 20 = 640 Kbit/s. 

La partie montante de la communication est decoupee en 256 tranches de 4,3 kHz. 
Toujours pour un transport de 8 bits par intervalle de temps, on arrive au debit de : 

4 000 x 8 bits x 256 = 8,2 Mbit/s 

II est possible d'ameliorer le debit en augmentant le nombre de bits par intervalle de 
temps. 

Des versions simpliflees de modems ADSL sont parfois mises en oeuvre dans certains 
pays, telles que l'ADSL Lite, ou G-Lite, et U-ADSL (Universal ADSL). L'objectif de 
cette simplification est d'offrir un acces a Internet a tres bas prix. Les capacites de trans- 
mission sont respectivement de 1,5 Mbit/s et 512 Kbit/s. Des cartes ADSL Lite sont 
commercialisees pour les PC. 

Les modems G-Lite ressemblent aux modems ADSL, mais ils sont capables de s' adapter 
aux possibilites de la ligne. Le modem G-Lite ne se place pas a cote de la communication 
telephonique, comme dans l'ADSL, mais prend toute la capacite de la ligne. En particu- 
lier, le modem s'interrompt si une communication telephonique doit passer par la ligne. 
Les modems G-Lite s'adaptent bien aux acces haut debit, en particulier pour l'ATM. 
Dans ce cas, le protocole PPP (Point-to-Point Protocol) peut etre utilise. II a ete standar- 
dise dans cette configuration par l'ADSL Forum et 1' ANSI. Nous revenons sur les proto- 
cols utilises par les modems ulterieurement dans ce chapitre. 

L'ADSL Forum a deflni 1' interface a respecter. Cette derniere a commence par suivre 
1' architecture ATM, deploy ee par les operateurs et les equipementiers du secteur des tele- 
communications vers le debut des annees 90. A cette epoque, l'ATM representait une 
potentialite forte pour 1' unification des reseaux des annees 2000. Depuis quelques 
annees, la technologie Ethernet prend le dessus, et la plupart des modems ADSL sont 
aujourd'hui des modems Ethernet. 
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Les octets provenant des differentes sous-bandes sont encapsules dans des trames ATM 
ou Ethernet. Les trames ATM ou Ethernet sont elles-memes encapsulees dans une trame 
de niveau physique, ou supertrame, qui correspond a la vitesse de l'acces ADSL. Par 
exemple, pour une connexion d'une capacite utile de 1,5 Mbit/s, les trames ATM sont 
transmises dans une supertrame de 68 cellules ATM, plus une cellule de synchronisation. 
Chaque supertrame demande un temps de 17 ms pour etre emise, ce qui correspond a un 
peu moins de 250 us par trame. La vitesse de transmission utile pour le client atteint dans 
ce cas 1,5 Mbit/s, une fois enlevees les synchronisations et les bits de redondance ou de 
correction d'erreur. 

Ethernet dans le premier mile 

L'lEEE a promulgue un standard pour 1' utilisation d' Ethernet sur la boucle locale. Appe- 
lee EFM (Ethernet-in-the-First-Mile), cette solution au debit symetrique de 10 Mbit/s 
devrait permettre aux entreprises de se connecter a Internet en mode symetrique a haut 
debit. L'avantage est d'utiliser les paires torsadees telephoniques, deux paires en l'occur- 
rence, et done de permettre a un cout faible une connexion a un debit acceptable. Cette 
solution correspond a la norme IEEE 802.ah. Elle est limitee a une distance de 750 m a 
10 Mbit/s et de 2 700 m a 2 Mbit/s. 

Une extension a 50 Mbit/s est en cours de normalisation avec 8 paires de fils metalliques 
torsades sur une distance de l'ordre du kilometre. Pour depasser cette distance, il faut 
faire appel a de la fibre optique, qui permet en EFMF (EFM Fiber), avec une fibre en 
monomode, d'atteindre des vitesses de 100 ou 1 000 Mbit/s jusqu'a des distances de 
l'ordre de 10 km. Comme nous le verrons, les techniques PON (Passive Optical 
Network) permettent d'allonger encore la distance a 20 km a des vitesses de 1 et bientot 
2,5 Gbit/s. 

Les DSLAM forment 1' autre extremite de la liaison, chez l'operateur. Le role de ces equi- 
pements est de recuperer les donnees emises par l'utilisateur depuis son equipement 
terminal au travers de son modem ADSL. Ces equipements integrent des modems situes 
a la frontiere de la boucle locale et du reseau de l'operateur. 

La figure 13.2 illustre le positionnement d'un DSLAM. 

Les lignes des abonnes a l'operateur local arrivent sur un repartiteur, qui permet de 
connecter l'utilisateur au commutateur telephonique et au DSLAM s'il a un abonnement 
DSL. Le DSLAM est lui-meme connecte a un concentrateur, que nous presentons un peu 
plus loin du point de vue protocolaire. Ce cas de figure est celui de l'operateur historique. 

Le degroupage designe l'arrivee d'operateurs alternatifs pour offrir des services tele- 
phoniques de donnees a haut debit et de video, comme la television. Parmi les diverses 
possibilites de realisation pratique du degroupage, la pose de cables a ete envisagee pour 
realiser une boucle locale differente de celle de l'operateur historique, lequel en possedait, 
jusqu'a la fin des annees 90, le controle total. 
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Figure 13.2 

Positionnement d'un DSLAM 
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En raison du prix tres eleve de la pose d'un reseau d'acces et de l'aberration que repre- 
senterait l'arrivee de plusieurs boucles locales jusque chez l'utilisateur, une par opera- 
teur, d'autres solutions ont ete adoptees. Certains operateurs ont choisi de se positionner 
au niveau du repartiteur. A partir de ce repartiteur, ils ont installe leurs propres 
connexions et leur propre DSLAM. 

L' inconvenient de cette solution provient de la situation geographique du DSLAM de 
l'operateur alternatif, qui doit se trouver dans une salle proche de celle de l'operateur 
historique. De plus, l'operateur alternatif doit tirer une liaison vers son propre reseau 
sans connaitre avec precision le nombre d'utilisateurs qui le choisiront. 

Une autre possibilite consiste a se positionner derriere le DSLAM en ayant son propre 
concentrateur ou bien, comme sur la figure, en se connectant a la sortie du concentrateur. 
L'operateur qui prend en charge la connexion entre le modem de l'utilisateur et la sortie 
du concentrateur s'appelle le fournisseur d'acces, ou NAP (Network Access Provider). 

Une derniere solution consiste a utiliser le reseau de France Telecom pour atteindre un 
POP (Point of Presence) de l'operateur alternatif. 

Jusqu'en 2004, les utilisateurs etaient obliges d' avoir un abonnement a France Telecom 
pour transmettre sur la boucle locale entre l'equipement terminal et le DSLAM. Desor- 
mais, le degroupage est total, et la facture de la communication sur la boucle locale est 
geree par l'operateur alternatif, qui doit malgre tout louer la ligne de la boucle locale a 
France Telecom a un cout decide par le regulateur. 



Les protocoles de I'ADSL 

L'utilisateur generant des paquets IP, il faut pouvoir transporter ces derniers vers le 
modem ADSL. Pour cela, on utilise soit une trame Ethernet, soit une trame PPP, soit une 
trame USB, soit une superposition de ces trames, comme une trame PPP encapsulee dans 
une trame Ethernet ou une trame PPP encapsulee dans une trame USB. 
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Prenons l'exemple de paquets IP encapsules dans une trame Ethernet. Cette trame est 
envoyee soit sur un reseau Ethernet reliant le PC du client au modem, soit dans une trame 
PPP sur une interface de type USB. Dans le modem ADSL, il faut decapsuler la trame 
pour recuperer le paquet IP puis l'encapsuler de nouveau, mais cette fois dans une trame 
ATM. Cette fragmentation en morceaux de 48 octets est realisee par le biais d'une 
couche AAL5 (ATM Adaptation Layer de type 5). 

Une fois la trame ATM arrivee dans le DSLAM, plusieurs cas de figure peuvent se 
presenter suivant 1' architecture du reseau du FAI auquel le client est connecte. Une solu- 
tion consiste a decapsuler les cellules ATM et a recuperer le paquet IP qui est transmis 
vers le concentrateur dans une trame Ethernet. Le concentrateur l'envoie vers le FAI 
egalement dans une trame Ethernet. Une autre solution consiste a laisser les trames sous 
forme ATM. C'est le cas lorsque l'operateur de la boucle locale et le FAI utilisent la 
meme technologic Dans ce cas, la cellule ATM est directement envoyee vers le concen- 
trateur, qui joue le role de commutateur ATM. Celui-ci envoie les trames ATM par des 
circuits virtuels vers des BAS (Broadband Access Server), qui sont les equipements inter- 
mediaries permettant 1'acces vers les reseaux des FAI alternatifs. 

Ces topologies sont illustrees a la figure 13.3. 

Fi 9 ure13 - 3 Utilisateur 

Equipements de concentration 
entre V utilisateur et le serveur 



DSLAM 




Concentrateur 



Une autre solution, qui est aussi tres utilisee, consiste a placer le paquet IP de depart dans une 
trame PPP et a garder cette trame tout le long du chemin, quitte a l'encapsuler dans 
d'autres trames. Cela a donne naissance au protocole PPPoE (PPP over Ethernet) dans le 
cas ou la trame PPP est emise sur Ethernet. La trame PPP peut etre encapsulee dans 
plusieurs trames ATM apres avoir ete decoupee en morceaux de 48 octets par le biais du 
protocole AAL5. 

L'avantage de conserver la trame PPP tout le long du chemin est de pouvoir l'encapsuler 
dans un tunnel L2TP. 
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Le protocole L2TP 

Pour realiser les communications entre les BAS et les serveurs, un protocole de tunneling 
doit etre mis en place puisque ce chemin peut etre considere comme celui a prendre par 
tous les paquets ou trames provenant des differents DSLAM et allant vers le meme 
serveur. 

Le tunneling est une technique courante, qui ressemble a un circuit virtuel. Les trois 
protocoles utilises pour cela sont PPTP (Point- to-Point Tunneling Protocol), L2F 
(Layer 2 Forwarding) et L2TP (Layer 2 Tunneling Protocol). Ces protocoles permettent 
rauthentification de l'utilisateur, 1' affectation dynamique d'adresse, le chiffrement des 
donnees et eventuellement leur compression. 

Le protocole le plus recent, L2TP, supporte difflcilement le passage a l'echelle, ou scala- 
bilite, et n' arrive pas a traiter correctement et sufflsamment vite un nombre de Hots 
depassant les valeurs moyennes. Dans ce cas, on ajoute des concentrateurs d'acces L2TP, 
ou LAC (L2TP Access Concentrator), qui recuperent tous les clients provenant d'un 
meme DSLAM et allant vers un meme BAS et les multiplexent sur un meme circuit 
virtuel. 

La figure 13.4 illustre T architecture protocolaire d'une communication d'un PC vers un 
serveur situe dans un reseau de FAI different de celui de l'operateur d' entree. Le PC 
travaille sous TCP/IP et est connecte a un modem ADSL par le biais d'un reseau 
Ethernet. 
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Figure 13.4 

Architecture protocolaire d'une communication ADSL 
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Les modems VDSL 

Les modems VDSL (Very high bit rate DSL) permettent d'atteindre des vitesses beau- 
coup plus elevees que les modems ADSL, mais sur quelques centaines de metres seule- 
ment. Leur capacite est de plusieurs dizaines de megabits par seconde. Les modems 
VDSL peuvent se mettre a la sortie d'un PON (Passive Optical Network), que nous 
decrivons un peu plus loin, pour prolonger leur liaison vers l'utilisateur. Les PON 
pouvant etre en technologie ATM. Les modems VDSL doivent en ce cas accepter la 
trame ATM. Aujourd'hui, on commence toutefois a developper des E-PON (Ethernet 
PON). 

Les debits peuvent etre asymetriques ou symetriques, au choix de l'utilisateur. Selon les 
propositions de l'ANSI, les debits en asymetrique atteignent 6,4 Mbit/s dans le sens 
montant et 52 Mbit/s dans le sens descendant sur une distance de 300 m. Pour une 
distance de 1 000 m, il devrait etre possible d'obtenir la moitie des debits precedents. 
La bande de frequences situee entre 300 et 700 kHz est devolue a la bande montante. La 
partie du spectre situee entre 700 kHz et 30 MHz sert a la bande descendante. La partie 
basse du spectre est reservee a la parole telephonique classique de l'operateur France 
Telecom. 

Comme dans le cas de 1' ADSL, un nitre permet de separer la partie telephonique classi- 
que, qui va vers un repartiteur telephonique, et la partie donnees, qui va vers 1' equivalent 
d'un DSLAM, lequel peut utiliser la fibre optique du PON pour atteindre le local technique 
de l'operateur. 

Le reseau d'entreprise, a la sortie du modem VDSL, peut etre de deux types : ATM ou 
Ethernet. Dans le premier cas, les trames ATM sont directement acheminees sur ce reseau 
par un commutateur ATM connecte au modem. Dans le second cas, un hub Ethernet est mis 
en place, complete par un routeur. 

La parole et la video sur xDSL 

Nous avons vu qu'en xDSL la parole telephonique classique etait transportee parallele- 
ment aux donnees sur la partie basse du spectre. Cette technologie convient tres bien aux 
operateurs historiques, aussi appeles ILEC (Incumbent Local Exchange Carrier). Les 
nouveaux venus, ou CLERC (Competitive Local Exchange Carrier), peuvent aujourd'hui 
esperer concurrencer les operateurs historiques grace a la dereglementation de la boucle 
locale. 

Pour prendre en charge des clients sur la boucle locale de l'operateur historique, ces 
operateurs entrants font passer la parole telephonique sur la partie DSL. On appelle cette 
solution ToDSL (Telephony over DSL). Le passage de la parole sur la partie donnee 
rentre bien dans la categorie de la TolP. 

Les paquets de parole devant arriver au recepteur avant 150 ms, il faut qu'une priorite 
leur soit appliquee. Dans ce cas, la dizaine de kilobits par seconde de la parole compres- 
see passe assez facilement. II faut toutefois que la priorite puisse s'exercer non seulement 
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sur la partie modem mais aussi sur les parties reseau precedant et suivant les deux 
modems. Cela suppose, pour la partie reseau d'entreprise, 1'application d'une technique 
de priorite et, pour le reseau du FAI, la possibilite de negocier un SLA (Service Level 
Agreement) compatible avec le temps maximal de traversee de bout en bout. 

Une autre solution, moins integree mais plus simple a mettre en ceuvre, est commerciali- 
see par de nombreux FAI pour offrir un service telephonique de type ToDSL. Elle 
consiste a utiliser une bande specifique du modem de 4,3 MHz, offrant un debit de 
32 Kbit/s. L' inconvenient de cette solution est que si la parole telephonique n'est pas 
utilisee, la bande passante correspondante est perdue. Cependant, comme la bande 
passante utilisee est tres petite, cela ne pose pas vraiment probleme. 

La ligne DSL doit aussi convoyer la signalisation telephonique, ce qui constitue la 
deuxieme difficulte apres la contrainte temporelle. Sur le modem, plutot que d' utiliser 
une priorite sur les donnees, il est possible d'utiliser l'AALl, qui offre des fonctionnali- 
tes de synchronisation et de priorite. Cette solution, appelee VoATM (Voice over ATM), 
est complementaire de la technologie ToDSL. 

La video est un deuxieme service qui peut etre offert par les modems xDSL. S'il est 
encore difficilement imaginable de voir ce systeme supplanter la video diffusee a grande 
echelle, la video sur DSL, ou VoDSL (Video over DSL), commence a etre deployee par 
de nombreux FAI pour des diffusions limitees et des services de VoD (Video on 
Demand). 

Ici encore, les deux solutions que nous avons examinees pour la telephonie sont possi- 
bles pour la video : soit on integre les paquets de video dans le flot en leur donnant si 
possible une priorite forte, soit on leur affecte un canal specifique. Dans ce dernier 
cas, la largeur de la bande passante affectee a la video differe suivant les operateurs 
pour aller de 800 Kbit/s a quelques megabits par seconde. Pour une television a 
800 Kbit/s, il suffit de recuperer 25 des 256 sous-bandes, chacune transportant 
32 Kbit/s. 

Dans le cas du multipoint, c'est-a-dire de la diffusion limitee a un petit nombre d'utilisa- 
teurs, la video est compressee en MPEG-4 ou eventuellement en MPEG-2 et emise en 
utilisant un protocole multipoint. Le plus performant de ces protocoles est IP Multicast, 
puisque les paquets sont a 1'origine IP. Cependant, comme il faut compresser au maxi- 
mum les donnees video, le choix du codec video est capital pour que le flot arrive dans 
les temps. 

La telephonie sur CATV 

Les cablo-operateurs disposent d'un environnement leur permettant de relier l'utilisateur 
a un ou plusieurs operateurs. Ce cablage est realise a partir du CATV (Community 
Antenna Television) reliant la tete de reseau aux utilisateurs, comme l'illustre la 
figure 13.5. Les canaux de television dans le sens descendant sont diffuses sur toutes les 
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branches du cablage. Dans le sens montant, les canaux doivent se superposer sur le tronc 
de l'arbre. 
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Figure 13.5 

Distribution de programmes TV par un cdblo-operateur 

Le cablage part d'une tete de reseau pour atteindre l'utilisateur apres une diffusion sur 
1' ensemble des branches du cablage. Dans le cadre de la diffusion de la television, les 
differents programmes sont tous pousses vers les utilisateurs. Chaque abonne re^oit 
1' ensemble des chaines et en selectionne une a visualiser. Cette technique est a 1' oppose 
de 1' ADSL, ou seule la chaine selectionnee par l'utilisateur est acheminee. 

Dans le CATV, une division en frequence est utilisee pour le transport des differents 
canaux de television (voir figure 13.6). La division en frequence donne naissance a des 
sous-bandes, chaque sous-bande portant un canal de television. 



Figure 13.6 
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La TolP est introduite de deux manieres differentes. La premiere consiste a affecter une 
bande etroite de 32 Kbit/s par utilisateur pour realiser de la TolP entre le combine de 
l'utilisateur et la tete de reseau qui est reliee a un operateur telecoms. La seconde 
revient a multiplexer le flux de TolP avec les donnees en allouant une priorite forte a la 
telephonic C'est cette seconde solution qui prend l'ascendant dans les technologies de 
CATV. 
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La ToIP passe done par une sous-bande pour la connexion a un operateur de type FAI. 
Cette sous-bande devrait etre sufflsante pour supporter la somme des debits crete des 
utilisateurs. Par exemple, 1 000 utilisateurs connectes a 1 Mbit/s, exigent un debit total 
potentiel de 1 Gbit/s. Cette valeur de 1 Gbit/s pourrait etre obtenue dans un avenir 
proche. Cependant, si le nombre d' utilisateurs sur une tete de reseau est de 10 000, voire 
beaucoup plus, la solution offrant une sous-bande speciflque a chaque utilisateur n'est 
plus possible. 

La solution a ce probleme consiste a choisir sur le CATV une bande assez large, actuelle- 
ment de 38 a 300 Mbit/s, et a utiliser une technique de multiplexage pour faire passer un 
maximum d' utilisateurs simultanement. La figure 13.7 illustre un partage de la bande 
passante d'un CATV en Amerique du Nord et en Europe. Les bandes montantes en 
Europe se situent entre 5 et 42 MHz et ont une largeur de 200 kHz a 3,2 MHz. Les bandes 
descendantes se situent entre 50 et 850 MHz, et la largeur des bandes de television est de 
8 MHz. 

Le nombre de bandes montantes et descendantes est laisse libre aux operateurs. Les 
valeurs pour 1' Amerique du Nord et l'Europe sont indiquees a la figure 13.7. Les bandes 
de television sont de 6 MHz. 



Figure 13.7 
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Pour realiser le multiplexage des utilisateurs sur la bande commune, deux grandes 
normes ont ete proposees : 

• IEEE 802.14, qui utilise une technologie ATM et qui est de moins en moins utilisee. 

• MCNS-DOCSIS (Multimedia Cable Network System-Data Over Cable Service Interope- 
rability Specification), qui a surtout ete utilisee en Amerique du Nord au depart, mais 
que les cablo- operateurs europeens ont adopte depuis quelques annees. Les versions 1 
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et 2 ont ete normalisees par l'UIT-T, et une version specifique pour l'Europe a ete 
realisee avec EuroDOCSIS. Les canaux de television PAL demandent une bande 
passante de 8 MHz contre seulement 6 MHz avec le systeme americain NTSC. Une 
version 3.0 de DOCSIS est en cours de normalisation, permettant de gerer 300 Mbit/s 
de flux descendant et 120 de flux montant. 

Pour realiser le multiplexage des utilisateurs sur la bande commune, la norme DOCSIS 
divise le temps en slots, numerates entre 1 et 4 096. Les deux standards disponibles, 
DOCSIS 1.1 et DOCSIS 2.0, utilisent des tables d' allocation de slots qui indiquent qui a 
le droit de transmettre dans un slot. Jusqu'a 14 slots peuvent etre utilises simultanement 
pour une meme communication. Les slots avec acces aleatoire, que Ton appelle slots de 
contention, permettent aux stations d'effectuer leur reservation. L' acces n'est pas vrai- 
ment aleatoire, puisqu'il utilise Talgorithme en arbre BEB (Binary Exponential Backoff) 
pour resoudre les collisions. 

La difference entre les deux standards reside dans la prise en charge de la qualite de 
service, qui n'est garantie que dans la version 2.0. Cette qualite de service est totalement 
compatible avec le modele DiffServ, presente au chapitre 6, qui consiste a marquer le 
champ de qualite de service de chaque paquet d'une valeur correspondant a son niveau de 
priorite. 

En conclusion, le CATV permet de faire passer de la telephonie sur IP, mais la 
version DOCSIS 2.0 doit etre choisie pour permettre l'obtention de la qualite de 
service necessaire. La version 3.0, qui utilisera IPv6, permettra une meilleure utilisa- 
tion de la bande commune tout en gardant le principe de la differenciation de classe 
DiffServ. 



La telephonie sur fibre optique 

La fibre optique commence a se developper dans la boucle locale pour desservir des 
applications a tres haut debit. La parole telephonique est ici multiplexee avec les autres 
applications, mais en y ajoutant une classification permettant aux paquets de telephonie 
de transiter sur la fibre en priorite. 

Nous ne ferons ici qu'introduire cette technologie, qui ne pose pas de probleme parti- 
culier pour le passage de la TolP, qui est multiplexee avec la plus haute priorite DiffServ. 
Comme nous allons le voir, ce sont la technologie Ethernet et done les fonctionnalites de 
classification DiffServ au niveau Ethernet, permises par le champ IEEE 802. lp, qui sont 
utilisees. 

Plusieurs technologies de fibre optique sont disponibles suivant 1' emplacement de la 
prise terminale. Cette prise peut etre chez l'utilisateur, ce qui donne naissance au FTTH 
(Fiber To The Home), ou a l'entree du batiment avec le FTTB (Fiber To The Building). 
Cette derniere solution est, par exemple, tres utilisee au Japon, completee par une techno- 
logie VDSL sur les derniers metres. 
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La solution FTTH permet d'atteindre des debits de 1 Gbit/s et FTTB + VDSL de 
80 Mbit/s. D'autres solutions sont egalement disponibles en arretant la fibre optique au 
trottoir, avec FTTC (Fiber To The Curb), voire au quartier pour desservir de petits 
DSLAM tres pres de l'utilisateur afin que des technologies Ethernet « first mile » puissent 
etre utilisees efficacement. 

Parmi les differents pays raccordes en fibre optique, le plus cable est certainement le 
Japon, ou NTT deploie un reseau optique depuis 1990. Ce deploiement a ete partielle- 
ment arrete lorsque les modems ADSL sont arrives sur le marche, avec en particulier les 
offres de SoftBank a bas prix. NTT a du concurrencer cette solution pendant plusieurs 
annees en offrant la meme technologic Aujourd'hui, le deploiement optique a repris. Les 
utilisateurs sont connectes a 100 Mbit/s et les entreprises a 1 Gbit/s. La fibre optique 
representait approximativement debut 2007 25 % du marche japonais de la connexion 
haut debit Internet. 

Le marche fran^ais est en attente d'un demarrage, tire essentiellement par France Tele- 
com et Free, mais qui attend une position officielle de l'ARCEP, 1' organisation de regu- 
lation franchise, avant d'investir massivement dans cette nouvelle technologic Cette 
attente concerne une potentielle deregulation du premier operateur. La position de 
l'ARCEP est de partager les investissements entre operateurs, la boucle locale optique 
etant degroupee de fait par cette proposition. 

Deux grandes solutions peuvent etre deployees, la fibre active et la fibre passive. 
Dans le premier cas, on retrouve la structure en etoile autour d'un repartiteur. La 
seconde solution, qui semble vouloir s'imposer, consiste a partager la fibre optique 
entre toutes les Internet Box d'arrivee. Le cablage est con^u avec des etoiles optiques 
passives, qui diffusent le signal dans toutes les directions. De ce fait, chaque station 
revolt une copie de 1' ensemble des flux qui partent de tous les points d'acces au 
cablage optique. 

L'avantage de cette solution est de permettre un partage total de la capacite de la fibre 
optique. Si un utilisateur n'utilise pas son acces ou peu, le trafic qu'il n'utilise pas peut 
etre recupere par les autres utilisateurs. Si Ton considere un cablage supportant le 
2,5 Gbit/s et que la tete de reseau supporte 48 utilisateurs, chaque client a un debit mini- 
mal moyen de 50 Mbit/s. En revanche, s'il n'y a que cinq utilisateurs, chacun a 500 Mbit/s. 
On peut done raisonnablement penser que 1' utilisation classique par utilisateur n' etant 
que de quelques megabits par seconde, un client pourra disposer a certains moments 
de 2,5 Gbit/s mais plus raisonnablement de 1 Gbit/s en tenant compte des contraintes de 
partage. 

La trame utilisee est principalement la trame Ethernet, ce qui donne naissance a la techno- 
logie E-PON (Ethernet Passive Optical Network). Le nombre de clients raccordes peut 
atteindre 64 et la distance 20 km avec un debit symetrique. 
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La telephonie sur Quadruple-Play 

La TolP se deploie aujourd'hui sur le Quadruple-Play, par la superposition de quatre 
medias, les donnees, la television, le telephone fixe de type TolP et la telephonie itine- 
rante. C'est a cette derniere fonction que nous allons nous interesser dans cette section. 

Nous avons aborde au chapitre 7 les developpements autour de la telephonie par Wi-Fi. 
La telephonie itinerante consiste a changer de technologie lorsque l'utilisateur se deplace 
sans couper la communication. 

Une premiere solution, developpee par BT (British Telecom) au Royaume-Uni, consiste 
en 1' utilisation de Bluetooth et du GSM. Lorsque l'utilisateur est chez lui, il est connecte 
par Bluetooth a son Internet Box, et lorsqu'il sort du rayon d'action de Bluetooth, il passe 
en GSM. 

Les solutions de Quadruple-Play developpees en France depuis juillet 2006 et au Japon a 
partir de Janvier 2007 as socient Wi-Fi et le GSM ou une autre technologie 2 G ou 3 G. La 
difficulty de cette approche est de passer d'une solution de TolP a une solution de type 
GSM. 

L' approche qui a ete choisie, en particulier par Orange, consiste a utiliser la technologie 
UMA (Unlicensed Mobile Access). Cette technique consiste a encapsuler la telephonie 
GSM dans des paquets IP. De ce fait, lorsque le client est connecte a Wi-Fi, un logiciel se 
trouvant dans le poste client encapsule les donnees de supervision et de telephonie GSM 
dans des paquets IP qui sont transportes par 1' intermediate du point d'acces Wi-Fi vers 
un controleur UMA ou UNC (UMA Network Controller). De ce fait, on emule la fonc- 
tion GSM au travers du reseau Wi-Fi. L'authentification du client est realisee par la carte 
SIM du GSM. 

Cette solution UMA permet de securiser la communication telephonique comme celle 
d'un GSM, mais ne permet pas d' exploiter les logiciels de signalisation de la TolP. 

Dans la solution Unik proposee par Orange, le telephone est bi-mode GSM/Wi-Fi. Lorsqu'il 
se trouve a portee d'un point d'acces, il se connecte en Wi-Fi, mais avec une emulation 
GSM. Lorsqu'il se trouve hors de portee de la cellule Wi-Fi de l'utilisateur, il fonctionne en 
mode GSM sur l'operateur cellulaire Orange. Le passage de l'un a l'autre s'effectue sans 
coupure de la communication dans le sens Wi-Fi vers GSM, mais pas dans l'autre sens. 

La securisation de la communication Wi-Fi est realisee grace a la cle secrete utilisee par 
le proprietaire de la LiveBox. L' inconvenient est de devoir modifier cette cle secrete lors- 
que le client veut se connecter sur une autre LiveBox que la sienne. Pour pouvoir se 
connecter a l'ensemble des LiveBox, il faudra attendre que la cle secrete de l'utilisateur 
puisse etre recuperee en temps reel ou que les bornes Wi-Fi des LiveBox disposent d'un 
deuxieme SSID (nom du point d'acces) permettant de construire un VLAN specifique 
pour les acces externes. 

Les solutions proposees par Free et Neuf Telecom sont assez differentes. Free propose 
deux categories de telephones. Le telephone Wi-Fi se connecte aux differentes FreeBox 
ay ant un acces Wi-Fi ouvert grace au chargement sur le telephone Free d'un logiciel 
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client mis en place par connexion sur la FreeBox de l'abonne. Cette solution permet a 
l'abonne de telephoner sur n'importe quelle FreeBox HD, au nombre de 300 000 
debut 2007. Le telephone GSM est un complement qui utilise les memes fonctionnalites sur 
la partie Wi-Fi et qui permet d'utiliser la puce GSM de n'importe quel operateur mobile. Le 
passage de Wi-Fi a GSM ne peut pas se faire sans coupure, la communication etant inter- 
rompue lorsqu'on sort du champ de couverture Wi-Fi. Dans ce cas, il faut rappeler en GSM. 

La solution Neuf Telecom est certainement la plus interessante, a l'exception du passage 
sans coupure Wi-Fi vers GSM de la solution Orange. Cette solution consiste a utiliser la 
puissance de la signalisation SIP. L'offre TWIN de 1' operateur permet de se connecter sur 
tous les acces Wi-Fi ouverts, qu'ils soient de Neuf Telecom ou d'operateurs concurrents. 
Par une signalisation SIP, l'utilisateur accede a son compte et telephone au prix de son 
abonnement Neuf Telecom. 

L' inconvenient majeur de cette solution est de ne pouvoir se connecter que sur les acces 
ouverts, puisque le telephone TWIN ne peut acquerir la cle secrete des utilisateurs de 
points d'acces a l'exception de celle de sa propre 9Box. En revanche, sur les hotspots, qui 
ne sont pas securises par une cle secrete, une fois l'authentification effectuee, le tele- 
phone TWIN peut fonctionner normalement. Le cout d'acces aux hotspots peut toutefois 
etre superieur a une communication telephonique GSM. Le passage ne s'effectue pas 
sans coupure entre les technologies Wi-Fi et GSM. 



Conclusion 



La telephonie sur IP a fortement augmente avec l'arrivee des modems ADSL, qui 
permettent a l'utilisateur d' avoir un debit important sur Internet. La parole telephonique 
ne demandant que quelques dizaines de kilobits par seconde, une surcapacite de la boucle 
locale permet une ToIP de bonne qualite puisque les paquets de parole pas sent rapidement. 

Si l'environnement DiffServ est fortement employe dans les entreprises, il ne Test pas du 
tout chez les particuliers. Cela vient du fait que la differenciation de trafic sur les Internet 
Box devrait donner lieu a une tarification. S'il y avait introduction de classes de service 
sans tarification, il est evident que tout le monde opterait pour la classe de plus haute 
priorite et que le probleme serait inchange. Comme les operateurs ne peuvent ni ne 
veulent s'entendre sur une tarification de la differenciation de service, il n'est pas possi- 
ble de l'introduire dans les Internet Box actuelles. La surcapacite reste la meilleure solu- 
tion sans classification, et c'est ce que permettent les modems ADSL. 

Nous avons introduit dans ce chapitre l'arrivee de solutions radio a partir des Internet 
Box pour completer les services Internet. Cela a engendre l'arrivee de nouveaux termi- 
naux associant la voix sur le GSM et la voix sur Wi-Fi. 

La partie terminale devenant de plus en plus hertzienne, de nouveaux reseaux radio sont 
en cours de normalisation, comme la technologie WiRAN (Wireless Regional Area 
Network), qui devrait permettre de faire passer par une seule antenne un million d'utili- 
sateurs de ToIP, mais evidemment nettement moins si Ton ajoute des donnees dans les 
communications des utilisateurs, sur une surface geographique a la taille d'une region. 
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L'un des problemes essentiels inherents aux protocoles de signalisation reside dans le 
filtrage des flux. Tres souvent, les entreprises utilisent des mecanismes de translation 
d'adresse (NAT), lesquels sont incompatibles avec les traitements appliques sur les flux 
multimedias. 

Les boitiers NAT et les pare-feu imposent les trois verrous suivants a la traversee des flux 
de ToIP : 

• Les protocoles de signalisation pour la ToIP standard, tels que H.323, SIP et MGCP, 
annoncent l'adresse IP des correspondants a l'interieur des messages qu'ils envoient. 
Or si ces adresses IP sont privees, elles ne sont pas exploitables en dehors du reseau 
local deployant le NAT. 

• Un boitier NAT n'effectue la correspondance d'une adresse IP locale privee avec une 
adresse IP publique correspondante que lorsqu'un terminal local effectue une 
connexion reseau. En consequence, si un terminal distant tente de joindre le terminal 
derriere le NAT, aucune regie n'est ajoutee dans le boitier NAT, et le correspondant 
derriere le NAT est injoignable. II peut emettre un appel, mais pas en recevoir. 

• Les ports utilises dans le canal de donnees sont negocies dynamiquement dans le canal 
de controle par les protocoles de signalisation. Un pare-feu ne peut done statiquement 
ouvrir les ports du canal de donnees puisque ces choix sont imprevisibles. 

Sauf a trouver des parades, ces verrous compromettent la traversee des reseaux d'entre- 
prise. Ce chapitre expose en detail cette problematique, en precisant comment fonctionne 
le NAT, a Torigine de ces verrous, pourquoi il reste d'un usage courant, quelles sont les 
differentes formes de NAT disponibles, quels sont les problemes rencontres et quelles 
solutions peuvent leur etre apportees. 
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Le mecanisme de NAT (Network Address Translation) 

Le protocole IP version 4, que nous utilisons massivement actuellement, offre un champ 
d'adressage limite et insufflsant pour permettre a tout terminal informatique de disposer 
d'une adresse IP. Une adresse IP est en effet codee sur un champ de 32 bits, ce qui offre 
un maximum de 2 32 adresses possibles, soit en theorie 4 294 967 296 terminaux raccor- 
dables au meme reseau. Pour faire face a cette penurie d' adresses, et en attendant la 
version 6 du protocole IP, qui offrira un nombre d' adresses beaucoup plus important sur 
128 bits, il faut recourir a un partage de connexion en utilisant la translation d' adresse, ou 
NAT (Network Address Translation). 

Ce mecanisme se rencontre frequemment a la fois en entreprise et chez les particuliers. 
II distingue deux categories d' adresses : les adresses dites publiques, c'est-a-dire visibles 
et accessibles de n'importe ou (on dit aussi routables sur Internet), et les adresses dites 
privees, c'est-a-dire non routables sur Internet et adressables uniquement dans un reseau 
local, a 1' exclusion du reseau Internet. 

Le NAT consiste a etablir des relations entre l'adressage prive dans un reseau et l'adres- 
sage public pour se connecter a Internet. 

Adresses privees et adresses publiques 

Dans le cas d'un reseau purement prive, et jamais amene a se connecter au reseau Inter- 
net, n'importe quelle adresse IP peut etre utilisee. Des qu'un reseau prive peut etre amene 
a se connecter sur le reseau Internet, il faut distinguer les adresses privees des adresses 
publiques. Pour cela, chaque classe d'adresses IP dispose d'une plage d'adresses reser- 
vees, definies comme des adresses IP privees et done non routables sur Internet. La 
RFC 1918 recapitule ces plages d'adresses IP, comme l'indique le tableau 14.1. 



Tableau 14.1 - 


- Plages d'adresses privees 


Classe d'adresses 


Plages d'adresses privees 


A 


10.0.0.0 a 10.255.255.255 


B 


172.1 6.0.0 a 172.31 .255.255 


C 


192.168.0.0. a 192.168.255.255 



Dans ce cadre, et avant d'introduire la notion de NAT, les utilisateurs qui possedent une 
adresse IP privee ne peuvent communiquer que sur leur reseau local, et non sur Internet, 
tandis qu'avec une adresse IP publique, ils peuvent communiquer sur n'importe quel 
reseau IP. 

L'adressage prive peut etre utilise librement par n'importe quel administrateur ou utilisa- 
teur au sein de son reseau local. Au contraire, l'adressage public est soumis a des restric- 
tions de declaration et d'enregistrement de 1' adresse IP aupres d'un organisme specialise, 
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1'IANA (Internet Assigned Numbers Authority), ce que les FAI effectuent globalement 
en acquerant une plage d' adresses IP pour leurs abonnes. 

La figure 14.1 illustre un exemple d'adressage mixte dans lequel on distingue les diffe- 
rentes communications possibles, selon un adressage de type prive ou public. 



132.10.11.121 
(Adresse IP publique) 



132.10.11.122 
(Adresse IP publique) 



10.0.0.2 
(Adresse IP privee) 




10.0.0.1 
(Adresse IP privee) 



Figure 14.1 

Adresses privees etpubliques 



132.227.165.11 
(Adresse IP publique) 



Partager une adresse IP privee 

Moyennant la souscription d'un acces Internet aupres d'un FAI, ce dernier fournit a ses 
utilisateurs une adresse IP privee. Dans un meme foyer ou une meme entreprise, deux 
utilisateurs ne peuvent communiquer en meme temps sur Internet avec cette seule 
adresse IP fournie. Les adresses IP privees conviennent generalement pour couvrir un 
reseau prive, de particulier ou d' entreprise, mais elles ne permettent pas de communiquer 
directement avec les reseaux publics. 
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Pour resoudre ce probleme et permettre a un terminal disposant d'une adresse IP privee 
de communiquer avec le reseau public, le processus de NAT fait intervenir une entite 
tierce entre un terminal, ayant une adresse IP privee, et tout autre terminal, ayant une 
adresse IP publique. Ce mecanisme consiste a inserer un boitier entre le reseau Internet et 
le reseau local arm d'effectuer la translation de 1' adresse IP privee en une adresse IP 
publique. Aujourd'hui, la plupart des borders, ou Internet Box, des FAI proposent a leurs 
abonnes cette fonctionnalite. Toutes les machines qui s'y connectent re^oivent par le 
biais du service DHCP une adresse IP privee, que le boitier se charge de translater en une 
adresse IP publique. 



10.0.0.1 
(Adresse IP privee) 



10.0.0.2 
(Adresse IP privee) 



10.0.0.3 
(Adresse IP privee) 



10.0.0.4 
(Adresse IP privee) 



10.0.0.254 
(Adresse IP privee) i^f 



132.227.165.221 
(Adresse IP publique) 



Passerelle NAT 



=f Reseau Internet < 



Figure 14.2 

Translation d' adresse s 



La figure 14.2 illustre un exemple dans lequel une passerelle NAT realise une translation 
d'adresses pour quatre terminaux. Cette passerelle possede deux interfaces reseau. La 
premiere est caracterisee par une adresse IP publique (132.227.165.221). Connectee au 
reseau Internet, elle est reconnue et adressable normalement dans le reseau. La seconde 
interface est caracterisee par une adresse IP non publique (10.0.0.254). Connectee au 
reseau local, elle ne peut communiquer qu'avec les terminaux qui possedent une adresse 
IP non publique de la meme classe. 

Lorsqu'un terminal ayant une adresse IP privee tente de se connecter au reseau Internet, 
il envoie ses paquets vers la passerelle NAT. Celle-ci remplace 1' adresse IP privee 
d'origine par sa propre adresse IP publique (132.227.165.221). On appelle cette operation 
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une translation d'adresse. De cette maniere, les terminaux avec une adresse IP privee 
sont reconnus et adressables dans le reseau Internet par une adresse IP publique. 

La translation d'adresses est bien sur realisee dans les deux sens d'une communication, 
afin de permettre remission de requetes aussi bien que la reception des reponses corres- 
pondantes. Pour cela, le boitier NAT maintient une table de correspondance des paquets 
de maniere a savoir a qui distribuer les paquets regus. Par exemple, si un emetteur dont 
l'adresse IP est 10.0.0.3 envoie vers la passerelle NAT un paquet a partir de son 
port 12345, la passerelle NAT modifie le paquet en remplagant l'adresse IP source par la 
sienne et le port source par un port quelconque qu'elle n'utilise pas, disons le port 23456. 
Elle note cette correspondance dans sa table de NAT. De cette maniere, lorsqu'elle rece- 
vra un paquet a destination du port 23456, elle cherchera cette affectation de port dans sa 
table et retrouvera la source initiale. 

Ce cas de figure est illustre a la figure 14.3. 



10.0.0.3 
(Adresse IP privee) 

I 
I 



10.0.0.254 
(Adresse IP privee) S 



132.227.165.221 
l (Adresse IP publique) 



-f Reseau Internet \ 



Passerelle NAT 






Envoi d'un 
paquet 



Adresse sou rce 
Port source 



10.0.0.3 
173*5 



Adresse sou rce 
Port source 



132.227.165.221 
7JZ5Z 



2) 



Table de NAT de la passerelle 



Port d'envoi 
73*55 



(IP source, Port source) 
(10.0.0.3, 12345) 



o\ Reception 
y) d'un paquet 



Adresse destination : 10.0.0.3 



Port destination : I^34b 



Adresse destina tion 
Port destination 



132.227.165.2 21 
234S6 



Figure 14.3 

Modification de paquets lors du NAT 



Avantages du NAT 

Le premier atout du NAT est de simplifier la gestion du reseau en laissant l'administra- 
teur fibre d'adopter le plan d'adressage interne qu'il souhaite. Etant prive, le plan 
d'adressage interne ne depend pas de contraintes externes, que les administrateurs ne 
maitrisent pas toujours. Par exemple, si une entreprise utilise un plan d'adressage public 
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et qu'elle change de FAI, elle doit modifier l'adresse de tous les terminaux qui compo- 
sent son reseau. Au contraire, avec le NAT et un plan d'adressage prive, le choix d'un 
nouveau FAI n'a pas d' impact sur les terminaux. Dans ce cas, l'administrateur n'a pas 
besoin de reconfigurer les adresses IP de tous les terminaux de son reseau. II lui suffit de 
modifier, au niveau de la passerelle NAT, le pool d' adresses IP publiques, qui est affecte 
dynamiquement aux IP privees des terminaux du reseau local. 

Le deuxieme atout du NAT est d'economiser le nombre d' adresses IP publiques. Le 
protocole reseau IP, qui est utilise dans 1' Internet actuel dans sa version 4, presente une 
limitation importante, car le nombre d' adresses IP disponible est faible compare au 
nombre de terminaux susceptibles d'etre raccordes au reseau Internet. Comme cette 
ressource est rare, sa mise a disposition a un cout pour les administrateurs qui souhaitent 
en beneficier. 

Le NAT comble cette penurie d' adresses propre a la version 4 d'lP en offrant la possibi- 
lity d'economiser les adresses IP a deux niveaux distincts. Tous les terminaux d'un 
reseau local n'ont pas forcement besoin d'etre joignables de l'exterieur, mais peuvent se 
limiter a une connexion interne au reseau. Par exemple, des serveurs d' intranet, des 
annuaires d'entreprise, des serveurs dedies aux ressources humaines avec des informa- 
tions confidentielles de suivi du personnel ou bien encore des serveurs de tests n'ont pas 
a etre joignables a partir du reseau Internet, mais seulement en interne au sein de l'entre- 
prise. En consequence, ces serveurs peuvent se contenter d'une adresse IP privee, qui ne 
sera jamais « nattee » par le boitier NAT puisque ces serveurs regoivent des requetes mais 
n'en emettent jamais. 

Un deuxieme niveau d'economie d' adresses IP publique est opere avec le mecanisme 
que nous avons mentionne a la section precedente, qui permet de masquer plusieurs 
terminaux disposant chacun d'une adresse IP privee avec une seule adresse IP publique, 
en jouant sur les ports utilises. Cette methode est tres couramment employee, car elle 
n'impose aucune condition quant au nombre de terminaux susceptibles d'acceder a Inter- 
net dans le reseau local. Elle n'en reste pas moins qu'un cas particulier du NAT. Nous 
verrons qu'elle est aussi la methode la plus contraignante pour recevoir des appels tele- 
phoniques. 

Un autre avantage important du NAT concerne la securite. Les terminaux disposent en 
effet d'une protection supplemental, puisqu'ils ne sont pas directement adressables 
de l'exterieur. En outre, le boitier NAT offre la garantie que tous les flux transitant 
entre le reseau interne et l'exterieur passent toujours par lui. Si un terminal est mal 
protege et ne dispose pas d'un pare-feu efficace, le reseau dans lequel il se connecte 
peut ajouter des mecanismes de protection supplementaires au sein de la passerelle 
NAT, puisqu'elle represente un passage oblige pour tous les flux. Globalement, l'admi- 
nistrateur concentre les mecanismes de securisation a un point de controle unique et 
centralise. Cela explique que, bien souvent, les boitiers NAT sont couples avec des 
pare-feu filtrant les flux. 
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Les trois categories de NAT 

Le mecanisme de NAT que nous avons pris comme exemple precedemment, consistant a 
jouer sur les ports pour masquer plusieurs terminaux avec une adresse IP unique, est un 
cas particulier. II repose sur une translation de port appelee NPT (Network Port Transla- 
tion). Lorsqu'elle se combine avec le NAT, on parle de NAPT (Network Address Port 
Translation). 

Bien que les concepts soient differents, le processus de NAT inclut frequemment par abus 
de langage le processus de NPT. En realite, il faut distinguer trois formes de NAT, le NAT 
statique, le NAT dynamique et NATP. Ces formes peuvent se combiner selon les besoins 
de chaque utilisateur et les politiques d' administration etablies dans un reseau. D'autres 
formes de classification du NAT sont possibles. La RFC 3489 en recense quatre types, 
par exemple. Nous nous contenterons de detailler dans les sections suivantes les formes 
les plus courantes. 

Le NAT statique 

Dans le NAT statique, a toute adresse IP privee qui communique avec l'exterieur, une 
adresse IP publique fixe lui est affectee. Avec ce type de NAT, les utilisateurs du 
reseau local sont joignables de l'exterieur, car la passerelle realise la correspondance 
d'une adresse IP locale en une adresse IP publique dans les deux sens. C'est un avan- 
tage indeniable, en particulier pour la telephonie, car un utilisateur a l'exterieur du 
reseau prive peut appeler un abonne a l'interieur du reseau prive puisqu'il connait son 
adresse IP fixe. 

Ce cas de figure est illustre a la figure 14.4. Le terminal ayant l'adresse IP privee 10.0.0.4 
n'a pas de correspondance d'adresse IP publique, car c'est un serveur interne. Les admi- 
nistrateurs font l'economie d'une adresse IP pour ce serveur et s'assurent en outre que ce 
dernier n'est pas joignable directement de l'exterieur. De plus, un changement de four- 
nisseur d'acces Internet ne remet pas en cause le plan d'adressage en local. 

Le NAT dynamique 

Avec le NAT dynamique, une plage d'adresses IP publiques est disponible et partagee par 
tous les utilisateurs du reseau local. Chaque fois qu'une demande d'un utilisateur local 
(avec une adresse privee) parvient a la passerelle NAT, celle-ci lui concede dynamique- 
ment une adresse IP publique. Elle maintient cette correspondance pour une periode fixe, 
mais renouvelable selon l'activite de l'utilisateur, qui assure le suivi des communications. 

Avec ce type de NAT, les utilisateurs locaux ne sont joignables de l'exterieur que s'ils 
ont une entree dans la table de la passerelle NAT, autrement dit que s'ils entretiennent 
une activite avec le reseau Internet. En effet, les correspondants externes ne peuvent 
s'adresser qu'a la passerelle NAT pour envoyer leur flux. Or tant que le correspondant 
interne n'a pas d' activite reseau, aucune entree ne lui est attribute dans la table de NAT. 
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10.0.0.1 
(Adresse IP privee) 



10.0.0.2 
(Adresse IP privee) 



10.0.0.4 
(Adresse IP privee) 



Figure 14.4 

Le NAT statique 




10.0.0.3 
(Adresse IP privee) 



De plus, 1' adresse IP qui leur est affectee est temporaire et peut etre differente a la 
prochaine connexion, ce qui restreint les possibilites d'etre joignable de l'exterieur. 

II existe meme une forme de NAT particuliere, appelee NAT symetrique ou « full cone » 
dans la RFC 3489, qui consiste a etablir une correspondance entre 1' adresse IP privee et 
publique selon la destination d'une communication. Autrement dit, un utilisateur du 
reseau local a une certaine adresse IP publique lorsqu'il communique avec un correspon- 
dant exterieur et une autre adresse IP publique lorsqu'il communique avec une autre 
destination. 

Le modele dynamique offre une plus grande souplesse d' utilisation que le modele stati- 
que puisque les associations d'adresses IP privees et publiques n'ont pas besoin d'etre 
mentionnees statiquement par l'administrateur, mais sont attributes automatiquement. 
En outre, il presente l'avantage d'optimiser au maximum les ressources. Si un utilisateur 
n'exploite pas sa connexion Internet et se contente de sa connexion locale, la passerelle 
NAT n'a pas besoin de lui attribuer une adresse IP. Le NAT dynamique est cependant plus 
complexe puisqu'il impose a la passerelle NAT de maintenir les etats des connexions 
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pour determiner si les utilisateurs exploitent leur adresse IP publique ou s'il est possible, 
passe un certain delai, de les reutiliser. 

Ce modele ressemble a celui deploye avec la telephonie RTC. Le nombre de lignes 
sortantes d'un commutateur telephonique d'entreprise et meme d'immeubles de particu- 
liers est generalement inferieur au nombre de lignes entrantes. Autrement dit, tous les 
abonnes disposent d'un telephone, mais tous ne peuvent appeler en meme temps. Dans la 
pratique, il est assez exceptionnel que tous les abonnes appellent en meme temps, si bien 
que ces derniers ne per^oivent pas cette restriction, qui permet aux operateurs de limiter 
le nombre de lignes. Avec le NAT dynamique, les notions sont differentes, mais le prin- 
cipe est le meme : 1' attribution des adresses IP se fait a la demande, avec les limitations 
du nombre d' adresses IP publiques disponibles que cela suppose. 



Le NAPT 



Variante du NAT dynamique, le NAPT (Network Address Port Translation) est en fait 
celui que nous avons presente precedemment sans le nommer. II consiste a attribuer une 
meme adresse IP a plusieurs utilisateurs d'un meme reseau local. 

Comme nous 1' avons explique, pour associer une meme adresse IP publique a deux 
terminaux ayant une adresse privee distincte, la passerelle NAT joue sur les ports des 
applications : une requete envoyee a partir du port A d' une source est retransmise avec le 
port B de la passerelle, tandis qu'une requete emise a partir du port C d'une autre source 
est retransmise avec le port D de la passerelle. De cette maniere, la passerelle peut 
controler et distinguer chacune des demandes qui lui parviennent. 

L' inconvenient de cette methode est que seuls les utilisateurs du reseau local peuvent 
amorcer une communication vers l'exterieur. Autrement dit, ils ne peuvent repondre a 
une communication qu'ils n'ont pas prealablement initiee. Les correspondants externes a 
la passerelle NAT ne possedent en effet des entrees que pour une adresse IP et un port 
source prives. Or si le port source est mentionne, c'est qu'une application a deja ete 
ouverte par le terminal du reseau local. Le correspondant externe n'a aucun moyen 
d'etablir une telle association en lieu et place du terminal dont il ignore la veritable 
adresse IP. 

Pour la telephonie, les utilisateurs qui ont ce type de NAT subissent la forte contrainte de 
pouvoir appeler un correspondant et communiquer avec lui mais sans pouvoir repondre a 
un appel. Certaines methodes, que nous detaillons ulterieurement dans ce chapitre, 
permettent cependant de contourner ces limitations. 

Le NAPT est sans conteste la methode la plus econome puisqu'elle permet de masquer 
tout un reseau local avec une seule adresse IP. Elle est la plus couramment employee chez 
les particuliers et les petites et moyennes entreprises. 
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Les problemes engendres par le NAT 

Pour etre pratiques et courantes, les fonctionnalites du NAT n'en posent pas moins des 
problemes de nature differente, comme les protocoles dits « sensibles » au NAT, la diffl- 
culte de recevoir une connexion derriere un NAPT ou la securite. 

Les sections suivantes detaillent chacun de ces problemes. 

Les protocoles sensibles au NAT 

Le probleme le plus important a considerer concerne les protocoles dits « sensibles » au 
NAT. C'est le cas des principaux protocoles de signalisation utilises pour les echanges 
multimedias, dont H.323, SIP et MGCP, mais egalement de bien d'autres protocoles, 
comme Kerberos, SNMP, DNS, ICMP ou encore les protocoles de partage de fichiers tels 
que FTP et les protocoles de mobilite tels que IP Mobile. 

Ces protocoles ne se contentent pas de mentionner leur adresse IP dans l'en-tete des 
paquets qu'ils envoient, mais ils l'indiquent egalement dans le corps de leurs messages. 
Par exemple, avec le protocole SIP, un message d' invitation invite comporte dans le 
paquet des informations sur 1' adresse IP de la source. Ces informations permettent 
d'etablir entre les correspondants la connexion dans laquelle les donnees veritables (la 
voix ou la video notamment) sont transmises. Dans cette situation, meme si le boitier 
NAT modifle 1' adresse IP source du paquet, le recepteur ne peut repondre correctement a 
la requete puisque cette derniere comporte une adresse IP source initiale, qui est une 
adresse privee. Le recepteur envoie done sa reponse vers 1' adresse IP source speciflee qui 
ne lui est pas accessible, et le paquet de reponse n' arrive jamais a son destinataire. 

Cette contrainte ne se pose pas pour toutes les applications. Par exemple, les flux d' appli- 
cation Web utilisent le protocole HTTP, dont les paquets ne contiennent pas 1' adresse IP 
de la source a l'origine de la requete. En consequence, le recepteur peut repondre sans 
connaitre de probleme de routage. Ce cas est en fait celui de la majorite des protocoles, 
mais pas des protocoles de signalisation tels que H.323 et SIP. 

Recevoir une connexion derriere un NAPT 

Ce probleme est specifique au NAPT, qui translate les utilisateurs a la fois selon une 
adresse IP et selon un port. La question qui se pose est de savoir comment sollicker une 
entite masquee derriere un boitier NAPT. 

Nous avons vu le cas ou un terminal en adressage local effectuait une demande de 
connexion. La table de NAPT est alors mise a jour conformement a la demande du termi- 
nal local, et la connexion avec l'exterieur peut se poursuivre. Mais comment faire si ce 
n'est pas le terminal local au boitier NAPT qui initie la connexion, mais un terminal 
distant ? Dans ce cas, le terminal distant ne sait pas vers ou envoyer sa demande de 
connexion, puisque la seule adresse publique est celle du boitier NAPT et que la table de 
NAPT ne contient a ce stade aucune entree permettant de determiner a qui est destinee 
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cette communication. En consequence, un terminal telephonique qui se trouve derriere 
une passerelle NAPT peut emettre un appel, mais pas en recevoir. 

Une solution elementaire a ce probleme pourrait consister a connaitre le port d'ecoute 
d'une application et a configurer sur le boitier NAPT une regie de redirection des paquets 
externes a destination de ce port d'ecoute vers une machine locale en particulier. Par 
exemple, tous les paquets rectus d' Internet a destination du port 34567 sont systematique- 
ment rediriges vers le terminal dont l'adresse IP est 10.0.0.2. Si ce dernier a configure 
son application pour utiliser le port 34567 comme port d'ecoute, la connexion devient 
possible. 

Malheureusement, cette solution n'est guere satisfaisante. Deux applications qui tournent 
sur deux terminaux distincts ne sont pas adressables simultanement. En outre, la proce- 
dure n'est pas automatique, et il est necessaire de configurer statiquement les regies de 
redirection, ce qui rend le mecanisme contraignant pour l'administrateur du reseau, en 
plus de ne pas etre toujours une fonctionnalite disponible sur les boitiers NAPT. Sur la 
majorite des equipements, les regies de redirection sont conflgurees au moyen d'une 
interface Web proprietaire. 

La securite avec le NAT 

Comme les codes de controle (checksums) inclus dans les en-tetes TCP d'un paquet sont 
calcules en fonction de l'adresse et du port du terminal source, ils deviennent invalides 
lorsque la passerelle NAT a modifle l'un ou 1' autre de ces deux elements. Si le destina- 
taire re^oit le paquet avec le code de controle initial, il considere le paquet comme 
corrompu et demande sa reemission. En consequence, la passerelle NAT doit recalculer 
les codes de controle et remplacer les originaux afln que les paquets restent valides et ne 
soient pas consideres par le destinataire comme corrompus. 

Pour cette raison, le mecanisme de NAT est davantage une parade a la penurie d'adresses 
IP qu'une veritable solution. II ne se met en place qu'au prix de traitements sensibles et 
pas toujours realisables. Par exemple, si l'emetteur crypte ses flux avec une couche IPsec, 
il devient impossible pour la passerelle NAT d'acceder aux en-tetes TCP des paquets 
relayes et done de les modifier, si bien qu'ils sont transmis de maniere erronee aux desti- 
nataires, qui les refusent. 

On peut considerer le NAT comme une forme de « hack », en ce qu'il impose une rupture 
entre un emetteur et son recepteur et ne respecte pas les en-tetes d'origine des paquets, 
puisqu'il doit retravailler certains champs pour que les paquets demeurent conformes aux 
specifications des protocoles. 

En resume 

Con^ue essentiellement pour faciliter 1' administration d'un reseau et offrir une solution 
de rechange aux restrictions d'adressage du protocole IP dans sa version 4, la translation 
d'adresses est aujourd'hui largement deployee, a la fois chez les particuliers et dans les 
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entreprises, sous differentes formes, plus ou moins restrictives. Elle fait neanmoins inter- 
venir, de maniere obligatoire, une entite tierce intermediaire entre l'emetteur et le recep- 
teur. Cette technique impose done des traitements supplementaires sur les flux. Or ces 
traitements ne sont pas toujours compatibles avec d'autres protocoles. En particulier, le 
NAPT bloque la reception d'appel. Surtout, les protocoles de signalisation les plus 
courants ne prennent pas en compte la translation d'adresses qui sera appliquee aux flux 
et inserent dans leur message des adresses privees, invalides pour un recepteur distant. 

II existe des parades pour lever ces verrous, que nous allons presenter et discuter dans la 
suite du chapitre. Au prealable, nous allons evoquer un autre verrou fort, celui concernant 
les pare-feu, que nous pourrons traiter avec les memes solutions que le NAT. 



Le passage des pare-feu 

Les pare-feu constituent des remparts indispensables pour se proteger des attaques exte- 
rieures. lis sont aujourd'hui couramment employes, a la fois par les particuliers et par les 
entreprises. Par le biais de regies de filtrage, ils inspectent tous les paquets qui transitent 
et verifient s'ils sont conformes a la politique de securite implementee. Si e'est le cas, les 
paquets sont autorises a traverser le pare-feu et a poursuivre leur cheminement vers leur 
destinataire. Si ce n'est pas le cas, ils sont detruits. 

Les pare-feu les plus classiques distinguent cinq elements qui caracterisent les flux : 
l'adresse IP de la source, le port utilise par la source, l'adresse IP du destinataire, le port 
utilise par le destinataire et enfin le protocole de transport specifie dans un paquet. Une 
regie de filtrage mentionne done la valeur de chacun de ces cinq elements et ordonne une 
action a entreprendre lorsque toutes ses valeurs sont validees. 

L' action entreprise revient soit a autoriser, soit a interdire le paquet, e'est-a-dire respecti- 
vement a laisser passer le paquet ou a le detruire. Typiquement, un pare-feu adopte pour 
politique de bloquer tous les paquets pour lesquels aucune regie d' acceptation ne 
convient. La politique inverse, consistant a autoriser tous les paquets pour lesquels 
aucune regie d' interdiction ne convient, est trop permissive. 

L'etat d'une connexion peut etre un sixieme element a prendre en compte par un pare- 
feu. Lorsqu'une communication est etablie avec les cinq elements precedemment 
mentionnes, on considere que la connexion est a l'etat actif ou etabli. Autrement, l'etat 
est considere comme inactif . 

On distingue ainsi deux categories de pare-feu : 

• Les pare-feu sans etat (stateless), qui ne maintiennent aucun etat des connexions et se 
contentent des cinq elements caracteristiques d'un flux precedemment cites pour auto- 
riser ou interdire les flux qui transitent dans le reseau. 

• Les pare-feu avec etat (statefull), qui maintiennent l'etat des connexions et sont capa- 
bles de distinguer si une communication s'effectue sur un port deja ouvert ou sur un 
port que le paquet demande d'ouvrir. 
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La notion d'etat est utile pour les protocoles a ports dynamiques. Avec des applications 
exploitant ces protocoles, une communication s'etablit sur un port fixe vers un destina- 
taire (canal de controle). Lorsque ce dernier est contacte, il convient avec l'emetteur de 
poursuivre la communication sur un autre port dynamiquement et arbitrairement selec- 
tionne (canal de donnees). De cette fa^on, il reste disponible pour servir un autre corres- 
pondant qui tenterait de le joindre ulterieurement sur le port fixe. Face a une telle situa- 
tion, seul un pare-feu avec etat est capable d'autoriser 1' usage du port dynamique. Pour 
cela, il lui faut analyser les paquets et determiner s'ils sont lies ou non a une connexion 
prealablement etablie. 

Imaginons a titre d'exemple un protocole dans lequel un destinataire demande a la source 
de remplacer le port statique initial par un port dynamique qu'il lui impose. Les trois 
etapes suivantes sont necessaires : 

1. La source emet un premier paquet vers un port fixe du destinataire. 

2. Le destinataire lui repond en precisant le port sur lequel il souhaite poursuivre la 
communication. 

3. La source reprend la communication en utilisant le port mentionne. 

Pour le pare-feu sans etat, seules les deux premieres etapes sont possibles puisqu'elles 
peuvent correspondre a une regie statique simplement fondee sur le « 5-uplets » initial. 
L'ouverture d'un port dynamique lui est impossible, car aucune regie n'en permet la 
definition, sauf a etre totalement permissive et a ouvrir tous les ports possibles, ce qui 
constituerait une pietre politique de securite. 

Pour le pare-feu avec etat, la troisieme etape est possible. En effet, ce type de pare-feu est 
capable d' analyser les flux et de determiner que le port dynamique sur lequel la source 
tente de communiquer correspond a la demande qui a ete faite precedemment par la 
destination. La gestion des etats offre une performance accrue dans le traitement des 
paquets, mais cela a un cout en ce qu'elle introduit une latence supplemental pour le 
pare-feu, qui doit en outre savoir analyser les protocoles correctement et, pour cela, 
connaitre leur syntaxe. 

L'etat est facilement discernable avec le protocole TCP, puisque ce dernier positionne des 
bits indiquant si la connexion est nouvelle, se poursuit ou se termine. Au contraire, le 
protocole UDP ne fournit pas ces indications. Pourtant, le pare-feu ne peut attribuer eter- 
nellement le statut actif a une connexion UDP. II alloue generalement le statut actif a une 
connexion UDP pendant un certain delai. Passe ce delai, la connexion est consideree 
comme perdue et devient par consequent inactive. 

Cette maniere de proceder est cependant tres approximative et ne convient pas aux appli- 
cations de TolP, qui utilisent tres majoritairement le protocole UDP pour transporter leurs 
donnees. Si, lors d'une communication, les intervenants cessent de parler, le silence 
correspondant n'est pas transmis, et aucun paquet n'est transmis durant cet intervalle de 
temps. Le pare-feu risque de considerer ce silence comme une terminaison de la commu- 
nication, ce qui est errone. 
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Un pare-feu est utile pour centraliser la politique de securite au sein d'un equipement 
unique. De cette maniere, la gestion du controle des applications autorisees n'est pas 
laissee au libre choix des utilisateurs, mais est a la charge du reseau, ce qui reduit les 
possibilites de contournement des regies edictees au sein de l'entreprise. 

Les fonctionnalites de NAT sont souvent implementees en parallele avec les fonctionna- 
lites de pare-feu. En effet, 1' operation realisee par le NAT comme par le pare-feu doit 
s'appliquer au niveau d'une passerelle, point de jonction entre le reseau local prive et le 
reseau public. En outre, dans ces deux fonctions, une notion de filtrage est requise. Lors- 
que les flux traversent le reseau, le boitier NAT detecte l'adresse IP source privee et la 
translate avec une adresse IP publique, tandis que le pare-feu inspecte l'adresse IP source 
pour savoir si l'utilisateur est autorise a emettre des flux. Dans le meme temps, le pare- 
feu detecte les ports et protocoles utilises par 1' application pour operer un filtrage avec 
une granularite plus forte. Autrement dit, 1' analyse des paquets est un mecanisme partage 
par les fonctions de NAT et de pare-feu, ce qui justifie leur couplage. 



Methodes de resolution de la translation d'adresse 
pour les flux multimedias 

Dans cette section, nous considerons une application dont les flux posent probleme parce 
qu'ils comportent dans le corps du message l'adresse IP de la source premiere, qui est 
une adresse IP non routable sur Internet. 

Differentes solutions permettent de resoudre les problemes engendres par la translation 
d'adresse. Certaines sont definies pour traiter des applications en particulier, tandis que 
d'autres sont plus generiques et peuvent s'appliquer a n'importe quelle application, pour 
peu qu'elle soit compatible avec le mecanisme mis en oeuvre. 

Filtrage applicatif des donnees 

Pour operer les modifications d'adresses IP et de port requises par la translation 
d'adresse, le boitier NAT doit imperativement connaitre le format et la syntaxe des proto- 
coles sous-jacents. Les protocoles utilises dans les couches basses de la communication 
reseau sont generalement classiques. Pour l'adressage IP, il s'agit du protocole IP 
(couche de niveau reseau) ; pour le port, il s'agit du protocole TCP ou UDP (couche de 
niveau transport). La majorite des flux sont done reconnus et peuvent etre traites. 

On peut generaliser cette idee. En connaissant les speciflcites d'un protocole, on peut 
operer exactement les memes modifications que celles effectuees avec le NAT pour 
l'adresse IP et le port. Meme si le probleme est plus complexe, puisqu'il existe de 
nombreux protocoles, cette solution demeure parfaitement fonctionnelle. Ainsi, le boitier 
NAT ne supporte plus uniquement les fonctionnalites de NAT classiques, mais est en plus 
capable d' analyser les flux pour determiner quels sont les protocoles utilises. En connais- 
sant la syntaxe de ces protocoles, le boitier peut effectuer toutes les modifications neces- 
saires. 
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La reponse apportee dans ce cadre est done une solution de filtrage de tous les protocoles 
utilises par les applications qui posent des problemes de NAT. 

Les passerelles de niveau applicatif 

Une nouvelle gamme de passerelles multimedias a ete mise au point pour permettre la 
reconnaissance des flux. Appelees ALG (Application Layer Gateway), ces passerelles 
sont proposees dans un grand nombre de solutions commerciales, embarquees le plus 
souvent au sein d'un pare-feu. Les flux sont flltres, et, s'ils sont reconnus, les modifica- 
tions necessaires au bon fonctionnement du NAT sont operees parallelement a l'autorisation 
accordee a ces flux de traverser le pare-feu. 

C'est dans cet esprit que le projet fibre Netfilter sous Linux (http://www.netfilter.org), propose 
la reconnaissance d'un tres grand nombre de protocoles, des couches basses aux couches 
les plus hautes. Les modules de reconnaissance sont egalement disponibles pour le proto- 
cole H.323 (modules ip_conntrack_h323 et ip_nat_h323), ainsi que pour le protocole SIP 
(modules ip_conntrack_sip et ip_nat_sip). Deux modules sont necessaires, le premier 
(ip_conntrack) realisant le suivi de connexion (car les flux utilisent des ports dynamiques 
qui doivent etre detectes durant la communication) et le second (ip_nat) realisant la trans- 
lation d'adresse. 

La technologie Netfilter est accessible par defaut dans toutes les distributions actuelles de 
Linux, par le biais de la commande iptables. Elle est fournie avec un ensemble de flltres 
pour la reconnaissance des protocoles les plus standards. Selon les distributions, le 
module de suivi de connexion n'est pas toujours fourni, mais peut etre facilement 
complete avec la technologie patch-o-matic, qui automatise les mises a jour de Netfilter. 

Cette solution est simple a mettre en oeuvre et transparente pour 1' application des utilisa- 
teurs. L' application n'a pas a modifier la structure des paquets envoyes. Le bolder se 
charge en emission (du reseau local vers le reseau Internet) de les rendre valides et en 
reception (du reseau Internet vers le reseau local) de les distribuer au terminal adequat. 

Le bolder NAT a une tache beaucoup plus lourde a accomplir puisqu'il doit filtrer des 
protocoles complexes, de niveau applicatif, ce qui reclame des ressources de traitement 
importantes. Cette fonctionnalite implique la reconnaissance des protocoles, mais aussi 
des traitements pour remonter jusqu'au niveau applicatif des paquets susceptibles de freiner 
les transmissions. On peut done lui preferer d'autres solutions. 

Tunneliser les applications 

Une autre solution pour resoudre les problemes du NAT consiste a adopter un tunnel de 
bout en bout, dans lequel le mecanisme du NAT n'a pas d'impact. Plus precisement, en 
etablissant un VPN (Virtual Private Network) entre l'emetteur et le recepteur, toutes les 
donnees que l'un ou 1' autre transmet sont acheminees a travers ce tunnel, qui garantit le 
routage correct des donnees. L'etablissement de ce tunnel peut etre realise avec les proto- 
coles L2TP ou IPsec, par exemple. 
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La figure 14.5 illustre l'etablissement d'un tunnel entre deux entites appartenant a des 
reseaux locaux distincts et disposant toutes deux d'adresses IP privees. 

Adresse IP privee 



Flux 
applicatifs 



Passerelle 
NAT 





Tunnel 



Flux 



applicatifs ^jm 

Adresse IP privee 



Figure 14.5 

Etablissement d'un tunnel pour le transport des applications 



Cette methode presente un double avantage : elle s' applique quelle que soit 1' application 
utilisee et ne requiert aucune adaptation, ni de la part des applications clientes, ni de la 
part de la passerelle NAT. Elle comporte neanmoins de serieux inconvenients, a 
commencer par le fait que l'emetteur et le recepteur sont contraints d'ouvrir un tunnel 
avant de proceder a leurs echanges. De plus, l'envoi des flux a travers un tunnel 
requiert des encapsulations protocolaires supplementaires, ce qui alourdit notablement 
les transmissions. 

L'etablissement d'un tunnel est parfois impossible avec le NAT. Comme indique prece- 
demment, le NAT doit modifier les en-tetes TCP, notamment le code de controle check- 
sum. Or certains tunnels cryptent ce champ, rendant impossible sa modification. 
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L' operation de NAT devient alors incomplete et invalide tous les paquets transmis. Enfin, 
dans une entreprise, si le tunnel crypte les donnees, il est probable que le pare-feu bloque 
les flux correspondants, puisque les flux inconnus sont potentiellement dangereux et le 
plus souvent contraires aux politiques de securite mises en place. 

La gestion du NAT par le client 

Pour reduire 1' implication et la charge du boitier, une autre approche consiste a reporter 
les modifications de l'adresse IP au niveau de 1' application elle-meme. Si 1' application a 
connaissance de l'adresse IP du boitier, il lui suffit de la reporter dans le corps de son 
message. Apres un NAT classique, le paquet emis devient completement valide dans le 
reseau Internet. De cette maniere, aucune modification n'est a apporter au boitier NAT, ce 
qui allege la gestion de ce dernier. 

Le premier probleme que Ton rencontre est qu'une application qui se trouve au sein du 
reseau local n'a aucun moyen de detecter l'adresse IP publique avec laquelle la passerelle 
NAT va translater ses flux. L' operation de NAT est totalement transparente pour l'utilisa- 
teur. II ne sait done pas avec quelle adresse les utilisateurs externes au reseau natte vont 
1' identifier. 

La methode UPnP 

Initialement prevue dans un cadre domestique, cette solution reste applicable dans tous 
les cas, comme l'explique 1' architecture generale de deploiement de UPnP (Universal 
Plug-and-Play) fournie sur le site http://www.upnp.org. 

Pour etre mis en oeuvre, le boitier NAT et 1' application cliente doivent tous deux suppor- 
ter ce mecanisme. L' application cliente sollicite dynamiquement le boitier NAT pour lui 
demander a la fois l'adresse IP publique et le port que le boitier va utiliser pour translater 
ses flux. Le boitier NAT qui ouvrira les ports dynamiquement selon les demandes du 
client est appele IGD (Internet Gateway Device). 

Son inconvenient principal est de presenter des problemes de securite importants inhe- 
rents a sa maniere de fonctionner. De plus, cette methode est limitee et ne peut fonction- 
ner si plusieurs NAT sont appliquees entre les correspondants. Pour des raisons evidentes 
de securite, cette methode ne doit pas etre generalisee. 

La methode STUN 

Le protocole STUN (Simple Traversal of UDP through NAT) apporte une solution plus 
efficace aux problemes du NAT. Defini dans la RFC 3489 de mars 2003, il permet aux 
terminaux de detecter dynamiquement le type de NAT qui leur est applique. 
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L'idee de base proposee par le protocole STUN consiste pour un client a demander 
l'adresse IP publique a un serveur externe, comme l'illustre la figure 14.6. En connaissant 
cette adresse, 1'application peut reporter 1'information dans ses messages. 



10.0.0.254 
(Adresse IP privee) 



132.227.165.221 
(Adresse IP publique) 



Passerelle NAT 



Requete : Avec quelle adresse IP suis-je visible sur Internet ? 



Reponse : Avec l'adresse IP : 132.227.165.221. 
£ 

Client STUN 

10.0.0.3 

(Adresse IP privee) 

Figure 14.6 

Requete-reponse entre un client et un serveur STUN 




Serveur STUN 



Le protocole STUN est conforme au modele client-serveur et distingue deux categories 
d' elements : 

• Le client STUN, entite qui emet des requetes STUN, doit se trouver dans un domaine 
prive. Le client STUN est implements au sein d'une application devant traiter et 
envoyer des donnees dont le contenu (hors en-tete) comporte des adresses IP. C'est 
generalement le terminal de l'utilisateur qui a ce besoin, mais il peut aussi s'agir d'un 
terminal quelconque. 

• Le serveur STUN, entite qui re^oit et repond aux requetes STUN. Pour executer 
correctement sa fonction, le serveur STUN doit se trouver a l'exterieur du reseau prive, 
generalement dans le reseau Internet. 

Le protocole STUN est standardise, ce qui en fait une methode a privilegier pour garantir 
aux applications la meilleure compatibilite possible. Son cout est modique, puisqu'il ne 
necessite que l'ajout d'un serveur, place a une position strategique. Le serveur regoit des 
demandes breves et y repond de fa^on analogue, ce qui en fait une entite faiblement solli- 
citee par chaque utilisateur. 
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Cette operation n'est toutefois pas transparente pour l'utilisateur, puisque les applica- 
tions doivent prendre en compte ce mecanisme dans les echanges qu'elles etablissent. 
De plus, la methode STUN, si elle supporte la majorite des types de NAT, ne s' appli- 
que pas au NAT symetrique. Dans ce dernier, en effet, la translation d'adresses depend 
egalement de la destination des messages envoyes. En utilisant le protocole STUN, 
1' appelant contacte un serveur STUN et est vu par ce dernier avec une adresse IP qui 
peut etre differente de celle que 1' appelant utilisera plus tard pour contacter son veri- 
table destinataire. Autrement dit, le serveur STUN retourne des informations d'adres- 
sage qui ne sont factuelles que pour lui et erronees pour tout autre correspondant. Le 
NAT symetrique lui echappe done. C'est pour resoudre ce probleme que la methode 
TURN a ete introduite. 

La methode TURN 

Le protocole TURN (Traversal Using Relay NAT) est actuellement a 1' etude. Soumis a 
1'IETF sous forme de draft depuis octobre 2003, avec une revision en juillet 2004, il a ete 
con^u pour lever les restrictions posees par la methode STUN et permettre aux utili- 
sateurs qui se trouvent derriere un reseau avec NAT ou derriere un pare-feu de 
communiquer quelle que soit la forme de NAT qui leur est appliquee. 

Comme pour STUN, l'idee est de disposer d'un serveur a l'exterieur du reseau natte, 
mais, contrairement a STUN, le serveur ne se contente pas d'informer le client de la 
forme de NAT qui lui est appliquee. II joue un role beaucoup plus actif et participe a 
l'acheminement des donnees en tant que relais. Un client qui souhaite etablir une 
communication avec un correspondant doit envoy er toutes ses requetes et donnees vers le 
serveur STUN, qui les transmet ensuite au correspondant. 

Le serveur doit dedier des ressources a ses utilisateurs en termes de bande passante. 
L'acces a ce service doit necessairement etre securise et restreint aux seuls utilisateurs 
qui sont autorises a l'utiliser. Dans la pratique, les clients partagent avec le serveur un 
secret partage permettant de les authentifier. Prealablement a leur envoi de donnees, les 
clients emettent une requete securisee par TLS. 

La encore, la communication doit etre initiee par le terminal local au mecanisme de NAT. 
En outre, le terminal local au NAT ne peut communiquer qu'avec un seul correspondant 
distant en passant par le serveur TURN. 

La plate-forme ICE 

ICE (Interactive Connectivity Establishment) n'est pas un protocole, mais une methodo- 
logie pour le passage des flux qui sont soumis a des translations d'adresses. Elle prescrit 
l'utilisation des protocoles STUN et TURN et fournit un cadre d'application au cas par 
cas. ICE est actuellement a l'etude sous forme de draft IETF. 
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En resume 



Les nombreuses solutions presentees dans cette section sont efflcaces, mais ne sont pas 
applicables dans tous les cas. La translation d'adresses est, par exemple, parfois incom- 
patible avec l'utilisation de tunnel VPN avec le protocole IPsec. Dans ce cas, lorsque les 
flux sont cryptes, il est impossible que le serveur en charge de la translation d'adresses 
intervienne pour modifier les paquets et assurer la liaison avec le correspondant. Du 
reste, l'utilisation de moyens de cryptage n'est pas toujours toleree par les pare-feu 
d'entreprise, qui veulent controler et pour cela reconnaitre les flux qui transitent sur le 
reseau. 

II existe cependant une solution de rechange au mecanisme de NAT. Proposee par 1'IETF 
sous le nom de RSIP (Realm Specific Internet Protocol), son objectif est similaire au 
NAT : prevenir la penurie d'adresses IP en deployant un adressage prive au sein d'un 
reseau local. Mais la maniere de proceder est differente et plus elegante. 

Avec RSIP, un terminal dans un reseau local possede une adresse IP privee qui lui est 
affectee pour communiquer localement comme avec le NAT. Pour pouvoir communi- 
quer avec le reseau public, le terminal doit sollicker une passerelle RSIP. Celle-ci 
affecte alors a l'utilisateur une adresse IP publique (dans le cas du NAT statique ou 
dynamique) ou bien une adresse IP publique avec un port TCP ou UDP associe (dans 
le cas du NAPT). 

Le terminal a done immediatement connaissance de 1' adresse IP publique avec 
laquelle il est visible sur le reseau, et il peut l'utiliser dans ses messages normale- 
ment. L' attribution de 1' adresse IP se fait pour une duree determinee, au-dela de 
laquelle la passerelle NAT s'autorise a attribuer de nouveau cette adresse IP. Nean- 
moins, le terminal peut negocier a tout moment une nouvelle demande pour conser- 
ver son adresse IP publique. 

Par ailleurs, s'ils en font la demande, les terminaux peuvent se voir attribuer plusieurs 
adresses IP correspondant a plusieurs reseaux locaux et publics, afln de pouvoir commu- 
niquer parallelement sur chaque reseau, tout en respectant la politique d' adressage 
propre a chaque reseau dans lequel elle communique. 

Les terminaux ne peuvent cependant se passer de faire transiter les flux par la passerelle 
RSIP et doivent encapsuler tout leur traflc dans un tunnel (de type GRE, IPsec ou autre) 
etabli avec leur adresse privee avec la passerelle RSIP. Celle-ci, en recevant les paquets 
de ce tunnel, decapsule simplement les parties d' adressage prive et envoie le paquet 
restant sur le reseau public. De cette fa^on, la passerelle RSIP reste indispensable pour 
garantir le masquage des elements du reseau local. 

Bien que globalement beaucoup moins utilise que le NAT, le protocole RSIP presente le 
grand avantage de ne pas necessiter, contrairement au NAT, de modifier dynamiquement 
les paquets au niveau de la passerelle. Des leur emission par les terminaux dans le reseau 
local, les paquets sont valides dans le reseau public. II est en outre compatible avec les 
mecanismes de NAT et peut cohabiter avec ces dernier s. 
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Conclusion 



L' adoption generalisee du protocole IPv6 permettra un adressage beaucoup plus impor- 
tant des terminaux. En principe, tous les terminaux de la planete pourraient avoir une 
adresse IP fixe. Mais cela ne resoudra sans doute pas totalement les problemes mentionnes 
dans ce chapitre. 

II n'est done pas certain que le NAT sera abandonne a l'arrivee du protocole IPv6. En 
masquant le veritable plan d' adressage d'un reseau local, le NAT contribue a securiser les 
terminaux, qui ne sont pas directement accessibles, mais uniquement joignables en 
traversant une entite effectuant le NAT et pouvant assurer des fonctionnalites comple- 
mentaires de controle. La gestion du reseau local est en outre independante de toute autre 
contrainte emanant du fournisseur d'acces. 

De plus, le besoin des utilisateurs de partager un adressage public ne sera pas forcement 
adapte au processus mis en place par les fournisseurs d'acces Internet. Ces derniers pour- 
ront a l'avenir continuer a ne distribuer qu'une seule adresse IPv6 a leurs abonnes et a 
recommander l'usage du NAT pour partager cette adresse ou bien operer de fagon trans- 
parente cette fonctionnalite a l'aide du boitier fourni. 

Les problemes du NAT etant par ailleurs couples aux problemes des pare-feu, notamment 
en ce qui concerne l'utilisation de ports dynamiques, il est probable que les solutions de 
rechange presentees dans ce chapitre seront encore mises a contribution pendant de longues 
annees. 



Partie 



Pour cloturer cet ouvrage, nous evoquons dans cette partie quelques aspects notables 
de la telephonie sur IP et tra^ons les grandes lignes des technologies et infrastructures 
potentielles de demain, sur lesquelles travaillent les principaux acteurs de la ToIP. 

Le chapitre 15 resume les points cles permettant de fournir un service de ToIP de 
qualite satisfaisante et conforme aux speciflcites des flux multimedias temps reel. 
II esquisse egalement 1' architecture GAN (anciennement UMA), qui est une orienta- 
tion possible des reseaux mobiles de troisieme generation, et qu'exploitent actuellement 
plusieurs operateurs telephoniques. 

Le chapitre 16 presente une alternative a GAN particulierement seduisante, et que 
poussent de tres nombreux industriels : IMS (IP Multimedia Subsystem). L'IMS defini 
un architecture qui s'appuie sur la capitalisation des protocoles et mecanismes deja 
existants dans le monde IP et s'adapte conformement aux contraintes des flux temps 
reel. Cette architecture a pour objectif de permettre la convergence des flux vers un 
reseau cceur unique, quels que soient les utilisateurs, leurs terminaux et surtout les 
reseaux d'acces utilises. 
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de laTolP 



La telephonie sur IP va ineluctablement remplacer la telephonie numerique classique. 
Les enjeux sont considerables puisque 1' ensemble des entreprises aura adopte cette techno- 
logie dans les dix annees a venir. 

Ce chapitre detaille les cinq problemes cles auxquels il est important de reflechir avant de 
decider de passer a la ToIR Ces problemes sont les suivants : 

• Securite. Dans les versions classiques de la telephonie, la securite est fortement 
garantie par un reseau speciflque, lequel ne peut etre attaque par remission de paquets 
d'attaque puisque le reseau n'est pas a transfert de paquets. Dans la ToIP, la conflden- 
tialite est assez simple a garantir par le biais de tunnels. Reste le probleme de l'authentifi- 
cation de l'utilisateur, qui merite reflexion. 

• Disponibilite. Dans la telephonie classique, la disponibilite est aux 5 « neuf », c'est-a- 
dire que le systeme est en etat de marche 99,999 % du temps. Dans la ToIP, elle passe 
aux 3 « neuf », soit 99,9 %, avec un bon fournisseur de service IP et plutot moins en 
general. La question est de savoir comment prendre en compte cette problematique 
pour revenir a des disponibilites plus acceptables. 

• Gestion. La gestion du reseau telephonique commute est relativement simple, 
puisqu'elle consiste a maintenir des circuits telephoniques. Avec l'integration de la 
ToIP dans le reseau de donnees, la gestion de l'environnement telephonique devient 
beaucoup plus complexe. Comment la nouvelle generation de reseaux integrant la 
ToIP va-elle pouvoir repondre a cette question ? 
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Controle. Comme la gestion, le controle de la telephonie est assez simple dans 
1' environnement unique des circuits numeriques. L' integration de la ToIP dans un 
reseau de donnees global complexifle grandement le controle, alors meme qu'il 
s'agit d'un service crucial compte tenu des contraintes temps reel de l'application 
de telephonie. 

Qualite de service. La telephonie par paquets est une application complexe, pour 
laquelle une excellente qualite de service est necessaire. Cette problematique ayant ete 
amplement commentee tout au long de l'ouvrage, nous n'y reviendrons que pour en 
resumer l'essentiel. 



La securite 



La securite est un probleme capital, bien que trop souvent delaisse pour diminuer les 
couts d'investissement, et qui pose des problemes qui ne sont pas toujours simples a 
resoudre. 

Dans la telephonie numerique, le systeme est quasiment ferme. Les commutateurs ne 
peuvent done etre atteints par des informations circulant dans le reseau. Cette particula- 
rity provient de l'unicite de l'application qui circule sur le reseau. Avec le multimedia et 
l'integration de la telephonie dans l'ensemble des donnees, il devient particulierement 
complexe de securiser l'application de ToIP. 

Les besoins concernent l'authentification, autrement dit la protection contre le piratage 
des identites, la confidentialite, e'est-a-dire l'impossibilite d'ecouter une conversation, 
l'integrite de la conversation et la defense de la vie privee (privacy) : 

• Authentification. C'est une des toutes premieres priorites si Ton veut que la confiance 
s'installe dans cet environnement. De nombreux mecanismes sont disponibles a cet 
effet, qu'ils soient normalises ou proprietaires. La norme la plus repandue provient du 
groupe de travail IEEE 802. lx que nous allons decrire. 

• Confidentialite. Les solutions resident dans le chiffrement. 

• Integrite. La signature electronique est une solution facilement exploitable. 

• Vie privee. II s'agit la encore d'un defl, bien que de premieres solutions apparaissent. 



L'authentification 



L'authentification consiste a identifier la personne qui se connecte ou a authentifier un 
utilisateur dont le nom n'est pas connu mais qui a donne les elements permettant de le 
reconnaitre, comme son mot de passe. 
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La solution d' authentification la plus repandue est fournie par la norme IEEE 802. lx. 
Elle est surtout employee dans le monde Wi-Fi pour obtenir l'autorisation de traverser un 
point d'acces. 

Cette solution utilise un serveur d' authentification de type RADIUS, qui contient le 
nom des personnes qui ont le droit d'acceder et un secret associe, comme leur mot de 
passe. L' authentification d'un client qui souhaite telephoner s'effectue simplement 
par l'intermediaire de ce protocole. Pour cela, il faut que le client puisse prouver qu'il 
connait une cle secrete, un mot de passe par exemple. Ce secret ne passe pas en clair 
dans le reseau. 

L' architecture qui permet de mettre en ceuvre l'algorithme associe est illustree a la 
figure 15.1. La norme 802.1x definit un controle d'acces du reseau fonde sur les ports. Sa 
fonction est d'authentifler et d'autoriser des equipements attaches au port d'un reseau 
local. 
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Figure 15.1 

Architecture d'authentification IEEE 802. lx 



Dans les reseaux sans fll 802.11, un port est une association entre une station et un point 
d'acces. Dans un reseau de TolP, le port est en general 1' association entre un telephone IP 
et un commutateur. Le port controle se comporte comme un interrupteur associe a deux 
etats. Dans l'etat unauthorized, seules les trames dediees a 1' authentification ne sont pas 
bloquees. Dans l'etat authorized, le flux de telephonie et plus generalement d'information 
transite librement. 
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Le protocole 802. lx definit les techniques d' encapsulation utilisees pour transporter des 
paquets EAP (Extensible Authentication Protocol) entre le port du client 802. lx et le port 
de l'equipement d'acces. Ces ports sont appeles PAE (Port Access Entity). 

Le mecanisme de gestion des ports et d' encapsulation est illustre a la figure 15.2 pour 
une ToIP sur Wi-Fi. EAPoL indique les debut et fin (optionnel) d'une session d'authenti- 
fication avec les messages de notification eapol-start et eapol-logoff. 
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Figure 15.2 

Mecanisme d' encapsulation et de gestion de ports de 802. lx 



Dans l'etat authorized, le port controle la duree de la session, c'est-a-dire le temps 
pendant lequel on considere que le client reste authentifie sans rien lui demander, a 
l'aide de la variable reAuthPeriod, dont la valeur par defaut est 3 600 s. En regie 
generale, le point d'acces retransmet les trames EAP perdues toutes les 30 s. De son 
cote, le client 802. lx retransmet les trames eapol-start non acquittees toutes les 
30 s par un message eap-request identity. Ces mecanismes sont illustres aux figu- 
res 15.3 et 15.4. 
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Dans les reseaux, le protocole EAP est utilise de maniere transparente entre la station et 
le serveur d'authentification au travers d'un equipement de reseau compatible 
IEEE 802. lx jouant le role d'« authenticator ». II est tour a tour encapsule par le proto- 
cole RADIUS, qui est routable puisque transports par IP. Ces encapsulations sont decri- 
tes a la figure 15.5 pour le cas d'un point d'acces jouant le role d'« authenticator », mais 
qui peut etre remplace par un equipement de reseau conforme a la norme 802. lx. 
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Figure 15.5 

Encapsulation des paquets sur le parcours entre Vutilisateur et le serveur d'authentification 



Schematiquement, l'insertion d'un terminal de ToIP dans un environnement 802. lx se 
deroule de la maniere suivante : 

1 . Le terminal s'authentifle puis s'associe a l'equipement d'acces, par exemple un commu- 
tateur Ethernet ou un point d'acces Wi-Fi. 

2. Afin de debuter l'authentification, le terminal emet toutes les 30 secondes une trame 

EAP-START. 

3. Le point d'acces ou le commutateur transmet un message eap-request.identity au 
terminal client 802. lx, qui produit en retour une reponse eap-response.identity 
comportant l'identite (EAP-ID) du terminal de ToIP. 

4. A partir de ce parametre, le point d'acces ou le commutateur deduit l'adresse (IP) du 
serveur d'authentification et transmet a ce dernier le message eap-response.iden- 
tity encapsule dans une requete RADIUS. 

D'autres possibilites ont ete implementees, comme 1' interrogation successive des 
serveurs RADIUS jusqu'a trouver celui qui est concerne par l'adresse IP. 
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5. Des lors, des messages EAP requete et reponse sont echanges entre le serveur 
RADIUS et le terminal client 802. lx, le point d'acces ou le commutateur ne jouant 
qu'un role passif de relais. 

6. Le serveur RADIUS indique le succes ou l'echec de cette procedure grace a un mes- 
sage EAP-SUCCESS ou EAP-FAILURE. En fonction de cette information, le port transite 
dans l'etat autorise ou non autorise. 

7. A la fin du processus d'authentification, le message RADIUS access-accept provo- 
que une transition dans l'etat authorized du port concerne. Le message RADIUS 
access-reject force le port concerne a l'etat unauthorized. Un port conserve son 
etat courant durant une session d'authentification. 

8. Dans le cas ou l'authentification est reussie, le terminal client 802. lx et le serveur 
d'authentification calculent une cle de session, baptisee Unicast Key. Dans l'environ- 
nement Microsoft, cette valeur represente un couple de cles de deux fois 32 octets 
(ces attributs sont dermis dans la RFC 2548 de mars 1999). Le serveur d'authentifi- 
cation transmet cette derniere au point d'acces ou au commutateur dans les attributs 
ms-mppe-send-key et ms-mppe-recv-key du message RADIUS ACCESS-ACCEPT. 

9. Le point d'acces ou le commutateur choisit alors une cle de chiffrement, dite Global 
Key, pour 1' association de securite avec le terminal client 802. lx. Cette derniere est 
chiffree et signee avec la cle de session re^ue du serveur RADIUS puis delivree au 
client 802. lx dans une trame eap-key. 

Le deroulement d'une authentification est illustre a la figure 15.6. 
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Les faiblesses de cet algorithme sont les suivantes : 

• L'identite du client passe en clair sur le reseau, ce qui est contraire a la protection de la 
vie privee. Des solutions sont proposees consistant a chiffrer le nom de la personne qui 
souhaite s'authentifier. Pour cela, il est possible d'utiliser une cle asymetrique. 

• L'entite qui gere le serveur d'authentiflcation peut connaitre les noms des personnes 
connectees. Pour le moment, peu de solutions permettent de resoudre cette question. 
On se dirige actuellement vers des solutions de tra^abilite fermee, grace au chiffrement 
des noms des personnes connectees. Seule une autorite judiciaire possedant la cle 
adequate peut dechiffrer les informations de tra^abilite. Le role des cartes a puce est 
important dans ce processus, puisque 1' information permettant la tra^abilite y reside et 
ne peut etre recuperee que grace a la cle maitre de 1' autorite judiciaire. 

Confidentialite et integrite 

Pour la confidentialite de la communication, les donnees doivent etre chiffrees. Le chif- 
frement s'effectue generalement par une cle symetrique, qui offre une grande rapidite du 
chiffrement et du dechiffrement. 

La difficulte reside dans la distribution securisee de la cle entre les deux extremites cornmu- 
nicantes. Une cle asymetrique peut etre utilisee pour le transport de la cle symetrique 
utilisee pour etablir le tunnel chiffre transportant la ToIP. 

L' integrite est obtenue par une signature electronique. La signature electronique s'effec- 
tue a partir d'un hash chiffre de 1' information a transmettre. Apres dechiffrement, le 
destinataire doit obtenir la meme valeur du hash. 

Nous voyons done que des solutions de securite efficaces peuvent etre implementees sur 
un reseau de ToIP. La plupart des solutions de telephonie sur IP implemented d'ailleurs 
ces fonctionnalites de fa^on plus ou moins ouverte. 

La disponibilite 

La disponibilite designe le temps pendant lequel un systeme est en etat de marche ou, ce 
qui revient au meme, le temps pendant lequel le systeme n'est pas en etat de marche. 

Comme explique precedemment, la telephonie classique presente une disponibilite dite 
aux 5 « neuf », e'est-a-dire que le systeme est en etat de marche 99,999 % du temps, ce 
qui represente cinq minutes de panne au total sur l'annee. Un bon FAI travaille aux 
3 « neuf », e'est-a-dire que son reseau est disponible 99,9 % du temps, ce qui equivaut a 
8,8 heures de panne par an. 

Beaucoup de FAI ne parviennent a un etat de marche que de 99 %, qui equivaut a trois 
journees de panne par an. Le cout pour grimper d'un facteur « neuf » est approximative- 
ment de 2. Plus le nombre de « neuf » augmente, plus le cout est eleve. En gardant ce 
facteur 2 a 1' esprit, on constate que le cout pour passer d'une disponibilite ordinaire a la 
disponibilite classique de la telephonie exige une multiplication du cout par presque 10. 
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II est possible d'implementer une redondance de tous les elements, reseau d'entreprise, 
acces, coeur de reseau, etc. Cette redondance est plus ou moins necessaire suivant le cceur 
de metier de l'entreprise. 

Pour une entreprise ou un operateur, il est important de determiner le taux de disponi- 
bilite vise en fonction de l'objectif a atteindre. De nombreuses solutions sont dispo- 
nibles pour gagner en disponibilite, a condition que 1' ensemble de la chaine soit mis 
au niveau. 

Pour la boucle locale, la solution optimale est de pouvoir etre connecte avec une ligne 
professionnelle a deux operateurs simultanement. Une ligne professionnelle apporte deja 
une garantie importante du fait d'un service de prise en charge des problemes en temps 
quasi reel. Les pannes peuvent neanmoins durer plusieurs minutes, ce qui equivaut a une 
disponibilite de 4 « neuf ». Cette disponibilite peut etre augmentee en utilisant deux 
connexions simultanees au meme operateur si le nombre de paires metalliques est, par 
exemple, de huit. Le mieux est encore d' avoir des operateurs differents afln de contourner 
les risques de panne d'un meme concentrateur DSLAM. 

Les operateurs augmentent pour leur part la disponibilite de leur liaison entre le DSLAM 
et le routeur de bord de leur reseau coeur en mettant en place non pas une liaison mais 
deux liaisons sur deux routeurs de bord differents. 

La derniere partie qui peut etre flabilisee est le reseau coeur lui-meme. Une redon- 
dance des chemins est generalement utilisee, avec de nombreuses strategies possibles. 
Ces strategies dites N:M impliquent que N chemins sont proteges par M chemins 
supplementaires. Le cas le plus classique est le 1:1, dans lequel un chemin possede un 
chemin de backup. II est toutefois aujourd'hui demontre que cette strategic n'est pas 
la meilleure, en particulier pour la protection des liaisons portant de la telephonie, car 
trop onereuse. 

Pour atteindre des disponibilites aux 5 « neuf » tout en gardant des couts acceptables, 
une redondance 4:2, voire 5:2, est preferable. Les deux lignes de backup peuvent 
d'ailleurs etre utilisees par des applications moins sensibles, qui peuvent etre supprimees 
ou degradees si la ligne de sauvegarde doit etre recuperee pour des liaisons telephoniques 
en panne. 

Les calculs permettant de deflnir le type de redondance a appliquer s'effectuent a partir 
des valeurs MTTF (Mean Time To Failure) et MTTR (Mean Time To Repair). Pour 
donner des ordres de grandeur des MTTR et MTTF utilises pour realiser des calculs de 
disponibilite au Etats-Unis, Telcordia a opte pour une valeur de MTTR de 2 h pour les 
routeurs et commutateurs et de 12 h pour une coupure de ligne passant par un domaine 
public, une panne de transmetteur optique tous les 3 800 jours et une panne d'un recepteur 
optique tous les 8 000 jours. 
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La gestion 



Avec la ToIP, il faut inclure les flux de parole dans le systeme de gestion du reseau, en 
particulier pour les pannes et la comptabilite. 

Le protocole classique SNMP est parfaitement utilisable dans ce contexte, mais des 
systemes dits d'« hypervision » doivent etre adaptes pour que la detection des pannes 
puisse se faire dans des laps de temps suffisamment courts pour ne pas compromettre la 
disponibilite du systeme. 

De meme, des dispositifs de configuration automatique des routeurs peuvent etre mis en 
place afin de configurer les conditionneurs de trafic a l'interieur des equipements de 
reseau pour prendre en charge les trafics de telephonic Ces flux sont mis en classe EF 
(Expedited Forwarding), selon la technique DiffServ normalisee par 1'IETF (voir le 
chapitre 7), ce qui demande une configuration specifique des routeurs. 

Une solution de configuration s'est fortement developpee depuis quelques annees grace a 
la technique PBM (Policy-based Management), qui permet a un systeme central de confi- 
gurer les equipements de reseau par politique. 

Le controle par politique necessite plusieurs composants (voir figure 15. 7). Les noeuds du 
reseau prennent le nom de PEP (Policy Enforcement Point). Les politiques y sont appli- 
quees pour gerer les flux des utilisateurs. Le PDP (Policy Decision Point) est le point qui 
prend les decisions et choisit les politiques a appliquer aux PEP. La communication entre 
le PEP et le PDP s'effectue par le biais d'un protocole ad hoc choisi entre plusieurs 
possibilites. Aujourd'hui c'est le protocole NetConf qui semble le plus utilise. 

Le systeme comporte egalement une console utilisateur, qui contient les outils de gestion 
des politiques. Ces outils permettent notamment d'entrer les politiques dans une base de 
donnees, nommee Policy Repository, qui entrepose les regies de politique que le PDP 
vient rechercher pour les appliquer aux noeuds du reseau. 

Des variantes de ce schema de base peuvent inclure plusieurs PDP susceptibles de gerer 
un meme nceud de transfert du reseau. Dans ce cas, les PDP ont des roles differents. Une 
autre variante autorise une decentralisation des fonctions du PDP dans des PDP locaux, 
appeles LPDP (Local Policy Decision Point). En regie generale, un PDP gere un seul 
domaine administratif, et les regies de politique sont communes a la configuration de 
1' ensemble des noeuds du domaine. 

Le PDP est defini comme une entite logique prenant des decisions politiques pour elle- 
meme ou pour d'autres elements reseau qui reclament ses decisions. Le PDP, que Ton 
peut aussi appeler serveur de politiques, est done le point central qui doit decider des 
politiques a appliquer dans le reseau. II s'agit en quelque sorte d'un organe de decision, 
qui recherche les informations dont il a besoin dans de nombreux serveurs communi- 
quant directement avec lui de fa^on a prendre une decision. Ces serveurs peuvent etre 
locaux, ce qui est le cas le plus general, mais ils peuvent aussi etre distants. 
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Figure 15.7 
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Les PEP sont aussi des entites logiques qui appliquent les decisions politiques prises par 
le PDP dont elles dependent. Les PEP sont generalement les noeuds du reseau, qui 
peuvent etre de differents types : routeur, commutateur ou LSR (Label Switched Router). 
Un PEP peut egalement etre un pare-feu ou un equipement intermediaire entre le client et 
le reseau. Le client peut lui-meme posseder un client PEP sur son terminal. 

Dans les reseaux de mobiles a carte a puce, il est frequent de considerer qu'un PEP 
d'acces se trouve sur la carte a puce. Son role est essentiellement reduit a la gestion de la 
securite et non de la qualite de service, mais il est imaginable d'implementer la 
gestion de QoS dans les cartes a puce des que celles-ci seront assez puissantes pour 
1'implementer. 

La technique PBM (Policy-based Management) ne peut cependant etre consideree 
comme une solution universelle, car elle depend aujourd'hui fortement des equipemen- 
tiers et de leur interface de configuration de leurs routeurs et commutateurs. L'avantage 
du standard NetConf, permettant les communications entre le PDP et les PEP, est d'utili- 
ser XML. Cette propriete le rend relativement independant des langages de configura- 
tion. Les routeurs et commutateurs doivent toutefois etre munis d'un interpreteur pour 
generer le code complet de configuration. 

Ce mode de gestion automatise par politiques ne concerne pour l'heure que les reseaux 
d'operateurs. Pour la gestion de 1' application de TolP elle-meme, des systemes de gestion 
plus classiques permettent d'implementer la surveillance des pannes, la planification, la 
securite, les performances et la comptabilite. 
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Le controle 



Le controle complete la gestion du reseau afin d'optimiser la configuration du reseau 
pour que les contraintes de la telephonie soient satisfaites. On distingue la gestion du 
controle par les temps de reaction et la mise en ceuvre dans le controle d'une boucle de 
reaction rapide. 

Le controle exige une boucle de retroaction capable de modifier la configuration du 
systeme si les temps de reponse deviennent inacceptables pour la telephonie. Les premie- 
res solutions consistaient a controler la congestion afin que les flux restent fluides a 
l'interieur du reseau. Cela revenait a maintenir le taux d'utilisation des ressources suffi- 
samment bas pour qu'il n'y ait pas de files d'attente importantes dans les nceuds. 

De nouvelles architectures, dites autonomes (autonomic) ont ete proposees, evaluees 
puis realisees. La figure 15.8 illustre l'apport principal de cette nouvelle architecture, qui 
reside dans l'introduction d'un « plan de connaissance » rassemblant les informations 
contextuelles afin de les mettre a disposition des algorithmes de controle presents dans le 
plan de controle. L'avantage de cette solution est de rassembler dans un plan unique les 
connaissances necessaires au pilotage du reseau, notamment au pilotage des algorithmes 
de controle des flux de ToIP pour que ceux-ci passent sans probleme. 



Plan « autonome» 



Plan des donnees 

Figure 15.8 

Architecture d'un environnement de controle « autonome » 

Cette architecture decrit un ensemble de quatre plans : 

• Le plan des donnees contient les couches basses de l'architecture des reseaux, c'est-a- 
dire les couches 1 a 4 du modele de reference ou 1' environnement TCP/IP. 

• Le plan de controle contient les algorithmes de controle du plan des donnees. On y 
trouve les algorithmes de routage de controle de flux, de controle de la qualite de 
service, de la securite, de la mobilite, etc. L'objectif de ces algorithmes est de faire 
fonctionner le plan des donnees d'une fa^on plus ou moins statique. 
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• Le plan « autonome » a pour objectif, d'une part, de mettre en place un algorithme de 
pilotage et, d' autre part, de mettre a la disposition du systeme de pilotage des connais- 
sances qui seront necessaires pour alimenter les algorithmes de controle. 

• Le plan de gestion a pour objectif d'administrer les trois autres plans. 

La nouveaute de cet environnement provient du plan « autonome », qui s'occupe de 
rechercher les informations et de les traiter (ce qu'on appelle les « connaissances »), et 
du systeme de pilotage, qui se nourrit des connaissances et qui en fait profiter les algo- 
rithmes de controle qui auront ete choisis et alimentes de fa^on adequate. 



La qualite de service 

La qualite de service est particulierement importante dans l'application temps reel qu'est la 
TolP. Comme nous l'avons vu aux chapitres 6 et 7, elle peut etre obtenue par differentes 
methodes, suivant que le reseau est commute ou route. 

Si le reseau est commute, les chemins utilises pour le transport des paquets peuvent etre 
dimensionnes par des techniques d'ingenierie de trafic. Si le reseau est route, des solu- 
tions comme DiffServ permettent de classifier le trafic et de surdimensionner le reseau 
par rapport au trafic prioritaire constitue essentiellement des paquets de parole. 

Lorsque des techniques de commutation sont utilisees, il s'agit generalement de reseaux 
MPLS (Multiprotocol Label- Switching). Ces reseaux concernent plutot les tres grandes 
entreprises et les operateurs. Dans ce cas, des chemins sont traces dans le reseau. Asso- 
ciees a ces chemins, des qualites de service suivent le plus sou vent la definition DiffServ. 

Les chemins de plus haute priorite, EF (Expedited Forwarding), garantissent la qualite de 
service grace a un calcul de trafic realise lors de l'ouverture de la connexion par le paquet 
de signalisation. La reservation de ressources effectuee permet de garantir les temps de 
transit necessaires a la TolP. Parfois, certains operateurs preferent ouvrir plusieurs 
chemins avec la qualite EF afin de differencier de fa^on encore plus precise la TolP 
d' applications metier qui se trouveraient dans la meme classe. Dans ce cas, la garantie est 
encore plus forte. 

Dans le cas d'un reseau de routage, que Ton trouve plutot dans les petites, moyennes et 
grandes entreprises, la qualite de service est assuree par la classe EF, mais la garantie est 
apportee non par une reservation de ressources mais par un surdimensionnement du 
reseau par rapport a la quantite de trafic EF. Ce calcul se complexifiant en fonction de la 
taille de l'entreprise, on passe a des techniques de reservation sur des chemins des que le 
trafic global devient trop eleve. 

Le calcul s'effectue sur les clients de la classe EF, qui provient de la TolP et de certains 
trafics metier. II faut reserver, pour ne pas avoir de surprise dans la suite, 100 Kbit/s par 
voie telephonique, qu'elle soit compressee ou non. En effet, nous avons vu que la taille 
minimale de la trame Ethernet etait de 64 octets ; si la parole est tres compressee, il n'y 
aura que peu d' octets telephoniques dans la trame, et si la parole n'est pas compressee, il 
n'y aura pratiquement que des octets telephoniques dans la trame. 
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II faut faire attention au cas des reseaux Ethernet a 1 Gbit/s, dont les trames ont une 
longueur minimale de 512 octets et dans lesquelles une voie de parole peut representer 
jusqu'a 500 Kbit/s si aucun element ne permet de multiplexer plusieurs voies de ToIP 
dans une meme trame. 

Ajoutons, pour conclure sur la qualite de service, que le protocole RTP/RTCP est une 
solution encore tres utilisee aujourd'hui pour compresser plus ou moins le flot telephoni- 
que en fonction de l'etat du reseau. L' application s'adapte ainsi au reseau, alors que les 
solutions plus modernes visent a ce que le reseau s'adapte a l'application. 



GAN 



GAN (Generic Access Network), anciennement UMA (Unlicensed Mobile Access), desi- 
gne une architecture de controle des reseaux permettant de passer d'un reseau disposant 
d'une couverture locale (un Local Area Network, ou LAN) vers un reseau disposant d'une 
couverture plus large (un Wide Area Network, ou WAN). 

Le modele GAN s'inscrit dans l'objectif de convergence entre les reseaux fixes et mobi- 
les, qu'on appelle CFM (convergence fixes mobiles), en anglais FMC (Fixed Mobile 
Convergence). GAN permet de realiser un basculement instantane (appele hand-over, si 
Ton reste dans le reseau de l'operateur, ou roaming, si Ton passe sur le reseau d'un autre 
operateur) d'un reseau IP vers un reseau non-IP, et inversement, sans rupture de la 
communication. 

Par exemple, l'utilisateur dispose d'un reseau d'acces IP sans licence (Wi-Fi, Bluetooth, 
ou autre), qu'on appelle UMA. En s'y connectant, il peut acceder a une passerelle 
connectee au reseau IP, appelee UMA Network Controller. Cette passerelle lui donne 
acces au reseau telephonique de son operateur. 

Lorsque l'utilisateur le desire, et sans qu'il y ait de coupure dans la communication en 
cours, il peut s'affranchir de son reseau d'acces UMA pour passer a un reseau avec 
licence, ou LMA (Licenced Mobile Acces), de type GSM, qui dispose d'une couverture 
geographique plus large, mais coute plus cher. 

Ainsi, l'utilisateur est libre d' exploiter deux supports d'acces pour acceder a ses servi- 
ces : un reseau IP, sans licence, ou bien un reseau non-IP, avec licence. Bien sur, cela 
suppose que le terminal de l'utilisateur soit bi-mode, c'est-a-dire qu'il supporte a la fois 
les connexions IP et les connexions mobiles. 

Plusieurs operateurs se sont d'ores et deja lances dans 1' exploitation du GAN, comme 
Orange, avec son offre UNIK, ou BT (British Telecom) avec Fusion. 

En exploitant son reseau personnel IP comme reseau d'acces, l'utilisateur fait economi- 
ser a son operateur 1' usage d'une infrastructure de reseau d'acces mobile de type GSM, 
qui est bien plus couteuse, ce qui s'en ressent dans sa facture. La fourniture de ce service 
est done moins chere mais elle est aussi plus reduite, car l'utilisateur est restreint aux 
seules zones de couverture IP auxquelles il a acces. 
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La combinaison des deux supports, IP et non-IP, constitue un ensemble coherent pour 
assurer la connectivite de l'utilisateur a tout moment, en tout lieu et dans les meilleures 
conditions. 



Perpsectives 



Dans les principaux pays developpes, la TolP se developpe a une vitesse acceleree, et 
plusieurs d'entre eux, parmi lesquels le Japon, la Coree, la Finlande et la France, ont deja 
annonce leur passage total a la TolP pour 2010 ou 201 1. 

Aujourd'hui, les taux de penetration de la TolP sont de l'ordre de 50 %, avec une crois- 
sance de 15 % par an. Les differentes applications de TolP d'entreprise, grand public et 
d' operateurs croissent de concert a des vitesses assez similaires. 

Une des questions posees par cet essor fulgurant de la TolP est le manque a gagner pour 
les operateurs. Les communications telephoniques vers tous les grands pays developpes 
sont aujourd'hui quasiment gratuites. La competition est telle pour attirer les clients que 
les gains, qui furent si importants dans la telephonie classique, tendent vers zero. 

Les benefices doivent done s'obtenir par d'autres services, eventuellement associes a la 
parole telephonique, ou par une meilleure productivite. Dans ces conditions, les opera- 
teurs doivent s' adapter et offrir de plus en plus de services pour pallier la disparition de la 
telephonie de type circuit. 

Les questions qui se posent sont encore nombreuses entre l'adoption d'une TolP d'opera- 
teur ou de type Skype, Wengo ou Vonage, ces dernieres presentant l'avantage d'etre 
gratuites, mais au prix d'une qualite de communication souvent insuffisante pour des 
usages professionnels. La qualite de service s'ameliore petit a petit a mesure qu'apparaissent 
des reseaux plus performants. 

De nombreux progres pourraient etre faits dans le domaine professionnel, mais les entre- 
prises rechignent devant les couts de deploiement. En particulier, la mise en place d'une 
politique de securite saine et la mise a niveau des equipements de routage et de commu- 
tation apportant une qualite de service suffisante aux flux de telephonie, ajoutees a 
l'investissement dans des telephones IP de qualite, impliquent des couts eleves, auxquels 
n'ont pas encore consenti les entreprises. 

Les problemes techniques qui restent a resoudre sont nombreux, en particulier l'integra- 
tion des environnements fixes et mobiles avec une facture unique, quel que soit le termi- 
nal utilise. La generation UMA, poussee par de nombreux operateurs pour realiser les 
handovers verticaux, n'est pas bien adaptee au monde IP, devenu majoritaire. Avec cette 
technologie, un reseau Wi-Fi se comporte comme s'il etait en GSM, ce qui ne va guere 
dans le sens de l'histoire. 

Le protocole IP devrait sortir vainqueur et s'imposer comme 1' architecture native du 
monde aussi bien fixe que mobile. L'IMS (IP Multimedia Subsystem), solution de 
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rechange a 1' architecture UMA pour l'integration flxe-mobile, se presente sous de bien 
meilleurs auspices puisque ses protocoles de base sont IP et SIP (Session Initiation 
Protocol). Cette solution devrait s'imposer vers la fin de la decennie pour permettre une 
convergence relevant davantage de l'univers Internet que de celui des telecommunications. 
C'est l'objet du prochain chapitre. 
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Globalement, le passage d'une situation ou plusieurs reseaux portent chacun un media 
specifique a un reseau unique multiplexant les medias a grandement complexifie les solu- 
tions. Comme nous l'avons vu dans ce chapitre, il existe des solutions a cette complexity, 
qui commencent a se repandre dans le domaine de la ToIP. Les freins a leur plein deploie- 
ment ne sont plus que le montant de l'investissement de depart, qui peut vite se reveler 
important pour de grands sites, et la disponibilite de telephones IP permettant une qualite 
de service, ce que les softphones n'offrent pas. 

L'avenir de la ToIP est tout trace. Lente a murir, elle s'impose dorenavant partout, aussi 
bien chez les particuliers que chez les operateurs. En se projetant plus loin dans le temps, 
elle va probablement se fondre dans les environnements multimedias et s'enrichir de 
1' image et de services evolues, la video sur IP ay ant des contraintes semblables en cas 
d'interactivite, mais a un debit beaucoup plus eleve. 

Un autre axe de developpement sera apporte par la telephonie en tout lieu et a tout 
moment, qui permettra d'entrer en contact avec n'importe qui, ou qu'il soit. Con^ue au 
depart pour remplacer la telephonie terrestre, la ToIP est aujourd'hui parfaitement acces- 
sible depuis un portable ou un PDA, voire un SmartPhone en y integrant une application 
de telephonie telle que Skype. Le trafic de telephonie utilise alors une voie de donnees 
integree dans le transport de donnees, que ce soit sur un reseau Wi-Fi ou WiMax ou sur 
un canal de donnees a une vitesse suffisante dans un reseau de mobiles. Si la couverture 
n'est pas assuree par une des technologies disponibles, le satellite peut prendre le relais, 
toujours par 1' intermediate d'un canal de donnees. 

D'autres applications de parole telephonique possedant des contraintes plus fortes passe- 
ront a terme en ToIP. Citons, a titre d'exemple, les applications d'urgences ou celles 
correspondant a des services en milieu difficile, comme la telephonie entre une tour de 
controle et les avions, qui ne peut etre coupee et dont la qualite doit etre suffisante pour 
une bonne comprehension. La disponibilite doit alors atteindre les 6 « neuf » et la qualite 
etre toujours au minimum celle de la telephonie classique. 



16 



L'architecture IMS 



Non content de s'etre impose dans les reseaux filaires, le protocole IP continue sa 
progression et son deploiement et commence a tisser sa toile dans les reseaux cellulaires, 
au detriment de la telephonie fixe traditionnelle. Rien ne semble pouvoir freiner son 
inexorable et prodigieuse ascension. 

Pour que le protocole IP gagne et s' impose definitivement face au modele a commutation 
de circuits, il semble que ce ne soit qu'une affaire de temps, et devolution des moeurs. 
Encore trop souvent, les utilisateurs rechignent a tenter le pari d'un tout-IP. Progressive- 
ment, la pratique, les couts et les fonctionnalites nouvelles font cependant tomber les 
dernieres reticences vers un monde IP. 

Cela etant, cette solution de rechange a la telephonie standard n'est qu'un premier pas 
vers la revolution des telecommunications qui se met en place sous nos yeux. En effet, 
maintenant que les technologies IP sont eprouvees et demontrent qu'elles sont suffisam- 
ment fiables et matures, l'etape suivante consiste a faire converger tous les reseaux 
d'acces (IP ou telecoms) vers une architecture unique. 

Le monde IP ne se limite pas a remplacer la telephonie traditionnelle : il l'enrichit d'une 
gamme de services evolues, diversifies et a moindre cout, qui a de quoi inspirer le monde 
des telecoms. Par exemple, une conversation sur Internet peut, dynamiquement et tres 
facilement, faire usage de la voix, de la video, de textes, de partages de documents 
(textes, images, sons et videos), d' applications en reseau, de securisation des communi- 
cations, etc. 

C'est ce marche du possible, deja conquis dans le monde Internet, mais qui echappe 
encore au monde des telecoms, que vient combler la nouvelle architecture appelee IMS 
(IP Multimedia Subsystem). 
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L' architecture IMS marque le developpement d'un nouveau type de reseau qui s'inscrit a 
la croisee d'lP et des telecoms. Comme son nom l'indique, IMS definit un sous-reseau 
multimedia ou plutot un reseau parallele aux reseaux actuels. Son ambition est le traite- 
ment des flux et services multimedias dans une optique de convergence, quel que soit le 
reseau d'acces utilise (GSM, Wi-Fi, Ethernet, UMTS, WiMAX, etc.), quelle que soit sa 
nature (fixe ou mobile), et quel que soit le type de terminal considere (ordinateur, PDA, 
telephone, etc.). 

Cette plate-forme revolutionne le monde des telecoms et accelere la profonde mutation 
de se secteur en ce qu'elle exploite le protocole IP pour gerer les communications entre 
les entites mises en place. La telephonie n'est plus le service, mais un service, parmi 
beaucoup d'autres. 

L'objectif de ce chapitre est de presenter TIMS en detaillant les motivations qui condui- 
sent les acteurs des telecoms a faire evoluer leur reseau vers IP, puis en decrivant histori- 
quement le developpement de 1'IMS. Nous presenterons ensuite l'architecture que 
propose IMS en introduisant ses composants, avant d'entrer dans le detail des communi- 
cations. 

Nous conclurons ce chapitre en evoquant les obstacles qui restent a franchir pour 1' adoption 
generalisee d'une architecture IMS. 

Motivations et objectifs de I'IMS 

C'est presque sous la forme d'un scenario publicitaire que Ton pourrait presenter 
l'objectif de I'IMS. Avec son telephone comment faire pour : 

• disposer d'un service de presence, c'est-a-dire connaitre la disponibilite de ses 
contacts avant meme qu'on ne les appelle ? 

• envoyer une photo, un numero de telephone ou une adresse postale durant une commu- 
nication ? 

• faire un achat en saisissant son numero de Carte bleue de maniere securisee ? 

• recevoir le bilan financier de son comptable pendant qu'on discute avec ce dernier ? 

• acceder a l'intranet de son entreprise ? 

• regarder une bande-annonce de film durant la reservation d'une place de cinema ? 

• initier une conference audio, puis, pendant la communication, basculer en mode confe- 
rence video, le tout en faisant varier dynamiquement le nombre de participants ? 

• modifier une presentation pendant que son correspondant la diffuse et la commente par 
telephone ? 

Les pistes pour certaines de ces actions ne manquent pas. Mais le constat general est 
flagrant : sur Internet, toutes ces taches sont triviales, interactives et sans coupure, alors 
que, avec un telephone, elles relevent de 1' exploit, coutent relativement cher et, surtout, 
sont tout sauf simples a mettre en ceuvre. 
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Certes, le terminal y est pour beaucoup, mais, de ce cote-la, les utilisateurs ont de plus en 
plus la possibilite de s'equiper de terminaux tres evolues et tres puissants, a la frontiere 
des ordinateurs. A des couts progressivement raisonnables, les ventes de PdaPhones et 
SmartPhones (avec en particulier le succes de l'iPhone) corroborent cet attrait de la part 
des utilisateurs pour des appareils de plus en plus sophistiques. 

Manifestement, le probleme ne se situe pas au niveau des terminaux, puisque l'equipe- 
ment existe et qu'il se democratise rapidement. Si les services telecoms restent a deve- 
lopper, l'objectif est de les placer a la hauteur de ceux disponibles dans le monde IP. Pour 
cela, l'idee de TIMS est d'installer le coeur du reseau telecoms dans le monde IP, afln de 
lui faire partager ses acquis et de permettre le developpement rapide de nouveaux services 
universels, accessibles quel que soit l'endroit ou Ton se trouve, quel que soit le reseau 
que Ton exploite et quel que soit le terminal que Ton utilise. 

Le point de vue operateur 

Le probleme : plusieurs reseaux d'acces, mais des besoins identiques 
partout 

Considerons les reseaux RTC (pour la telephonie traditionnelle sans IP), DSL (pour la 
telephonie IP) et GSM (pour la telephonie radio). 

Ces trois reseaux sont specifiques, et surtout autonomes. lis n'interagissent pas entre eux. 
Dans ce cadre, developper un nouveau service reseau revient inevitablement a le penser 
de maniere exclusive pour l'un de ces reseaux. 

Pourtant, ces trois reseaux sont susceptibles de fournir les memes services, a commencer 
par la telephonie, qui est disponible dans chacun d'eux, mais avec une architecture diffe- 
rente, des serveurs differents et un mode de fonctionnement different et incompatible, 
alors meme que le service est identique. 

La solution : mutualiser les ressources pour reduire les couts et simplifier 
la gestion des infrastructures des operateurs 

Aujourd'hui, les operateurs mettent en place une infrastructure distincte pour chaque 
reseau d'acces. Ainsi, on trouve un serveur d'authentification pour les acces dans les 
reseaux RTC et un autre pour les reseaux GSM. L' operateur doit done maintenir et gerer 
ces deux serveurs. On peut faire le meme constat pour les serveurs de facturation, ou plus 
largement les serveurs d' applications, qui sont propres a un certain type de reseau 
d'acces. 

On comprend facilement la motivation a l'origine de ce phenomene. Les reseaux d'acces 
ont ete con^us independamment les uns des autres, et ils ont connu un developpement 
parallele, de sorte qu'il etait difficile d'imaginer leur unification. La question n'en 
demeure pas moins : pourquoi continuer a maintenir deux architectures qui remplissent 
les memes fonctions ? 
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L' architecture IMS vise a deploy er une plate-forme dans laquelle chaque service peut 
etre gere par un seul serveur, et ce quel que soit le reseau d'acces. La vision de TIMS 
consiste a afflrmer haut et fort que les reseaux d'acces, s'ils different, ne sont jamais que 
des points d' entree et de sortie permettant de joindre les terminaux des correspondants. 
Au centre, le reseau coeur est different, alors que rien ne le justifle. L'idee est de faire 
converger tous les reseaux d'acces vers un meme reseau coeur, et done, quel que soit le 
reseau d'acces utilise, de disposer des memes couches de transport de 1' information, de 
controle des flux et d'acces aux services. 

La vision d'operateur verticale, dans laquelle les composants sont monolithiques et indis- 
sociables, est remplacee par une vision horizontale, dans laquelle les composants sont 
flexibles et modulaires. Les fonctions communes a l'ensemble des reseaux (comme 
l'authentification, la facturation et la fourniture des services) sont mutualisees dans des 
ressources partagees et centralisees. 

Un service intelligent 

Mutualiser les ressources ne signifie pas perdre les particularites de chaque reseau 
d'acces. 

Par exemple, si une requete parvient a un serveur, ce dernier ne repondra pas de la meme 
maniere selon que le terminal du client est un telephone mobile ou un PC. II doit impera- 
tivement faire la distinction entre les reseaux d'acces pour adapter ses reponses et fournir 
des resultats pertinents, par exemple selon le debit dont dispose l'utilisateur. 

Le point de vue utilisateur 

Le probleme : des scenarios d'utilisation differents mais des besoins analogues 

Aujourd'hui, l'utilisateur a autant de terminaux que de profils d' utilisateur. Or, pour un 
meme terminal, il n'est pas possible de faire la distinction entre une ligne professionnelle 
et une ligne privee. II est done necessaire d' avoir deux terminaux pour simplement diffe- 
rencier les parametres d'utilisation, alors meme que, fonctionnellement, un seul terminal 
telephonique sufflrait. 

L'utilisateur a de surcroit sou vent besoin d' avoir dans les deux terminaux des parametres 
communs, comme ses contacts ou son calendrier, dont il peut avoir besoin a tout 
moment, ce qui 1' oblige a multiplier les manipulations fastidieuses et redondantes sur des 
appareils qui, bien souvent, se configurent differemment. 

La solution : un terminal unique 

Le meme terminal pour la ligne fixe, a la maison comme au travail, et pour la ligne 
mobile, privee comme professionnelle : voila ce que nous promet l'IMS. 

Nos lignes telephoniques, et tous les services qui y sont associes, nous suivent, sans qu'il 
soit besoin de multiplier les terminaux, ce qui permet d'economiser et de simplifier 
considerablement les usages. 



(.'architecture IMS 



Chapitre 16 

Historique de I'IMS 

Puisque TIMS prefigure l'architecture des reseaux de demain, il etait logique que son 
developpement s'appuie sur les differents reseaux existants et que sa constitution tienne 
compte des differentes technologies en s'impregnant des tendances en cours, des besoins 
et des recommandations. 

Au depart, la question etait de savoir comment faire evoluer les reseaux cellulaires, c'est- 
a-dire de determiner les protocoles et architectures des futurs reseaux de telecommunica- 
tions. Le probleme est que, suivant l'endroit ou Ton se trouve, les standards utilises dans 
les reseaux cellulaires sont differents. Par exemple, en Europe la norme evolue du GSM 
vers l'UMTS tandis qu'en Amerique du Nord et partiellement en Asie, les produits 
s'orientent vers le CDMA 2000. II s'agit done de prevoir des evolutions vers des standards 
distincts. 

Pour cela, deux groupes de travaux ont ete formes, chacun devolu a Tune de ces normes : 
le 3 GPP (Third Generation Partnership Project), en charge de reflechir aux evolutions de 
la norme GSM, et le 3GPP2 (Third Generation Partnership Project 2), en charge de refle- 
chir aux evolutions de la norme CDMA 2000. Tous deux font partie de l'organisme de 
normalisation international IMT-2000 (International Mobile Telecommunications 2000), 
charge par l'UIT (Union internationale des telecommunications) de definir et de standar- 
diser les reseaux de mobiles de la prochaine generation. 

Cree en 1998, le 3GPP regroupe differents partenaires regionaux de la standardisation 
des telecommunications : l'ETSI (European Telecommunications Standards Institute) en 
Europe, le Comite Tl aux Etats-Unis, le CCSA (China Communications Standards Asso- 
ciation) en Chine, le TTC (Telecommunications Technology Committee) et l'ARIB 
(Association of Radio Industries and Business) au Japon et le TTA (Telecommunications 
Technology Association) en Coree. A ces partenaires, se sont ajoutes d'autres organis- 
mes et grands groupes industriels qui s'y sont affilie pour reflechir a des projets communs 
(UMTS Forum, IPv6 Forum, etc.). 

Le 3GPP ne reference pas ses documents de travail sous le nom de standards, mais sous 
celui de specifications techniques, ou TS (Technical Specifications), et de rapports tech- 
niques, ou TR (Technical Reports). Lorsqu'un ensemble de TS et de TR est complet et 
coherent pour former un tout decrivant exhaustivement les fonctionnalites attendues, 
1' ensemble est classe sous le nom de Release. L'IMS a ete defini dans la Release 
numero 5 du 3 GPP. 

En 2004, quatre groupes de travaux de l'ETSI, nommes SPAN, Signaling System N°7, 
Rl et Typhon, ont fusionne pour donner naissance au groupe de travail TISPAN (Tele- 
communications and Internet converged Services and Protocols for Advanced Networking), 
qui oeuvre dans le cadre du 3GPP pour TIMS. 

En 2005, TISPAN a propose une extension importante de TIMS a destination des 
reseaux filaires, lesquels, avant cela, n'etaient pas concernes par TIMS. La premiere 
version de TIMS adoptee par l'ETSI a ete proposee cette meme annee. Ces travaux ont 
ete repris et incorpores dans I'IMS des 2006, avec la publication de la Release 6 de 
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TIMS. La deuxieme version a ete proposee en 2007 (ajout de la VoD, d'IPTV et de la 
QoS). La troisieme (ajout de la mobilite generalisee et de la convergence) verra le jour 
en 2009. 

L' initiative 3GPP2 a ete lancee en 1998 comme un projet collaboratif pour la conception 
d'un reseau de troisieme generation partant sur la base des reseaux cdma2000 mis en 
place dans les reseaux cellulaires d' Amerique du Nord et d' Asie. II regroupe cinq parte- 
naires regionaux : TIA (Telecommunications Industry Association) en Amerique du 
Nord et les groupes ARIB, CCSA, TTA et TTC deja cites. A ces membres se sont joints 
des partenaires commerciaux et des industriels. 

Bien que les reseaux consideres au depart soient differents, ces deux instances de l'UIT 
ont les memes objectifs de convergence des communications vers un reseau tout-IP. Pour 
s'orienter vers un modele IP, et plutot que de reconstruire des protocoles, le 3GPP et le 
3GPP2 ont exploite ce qui existait deja et y ont ajoute ce qui devenait necessaire. lis 
travaillerent pour cela de concert avec 1'IETF afln de standardiser les protocoles utilises 
et d'y apporter des modifications : ces travaux concernaient en particulier les protocoles 
SIP, COPS, Diameter, DNS et IPv6. 

Au final les deux organismes, 3GPP et 3GPP2, proposent deux versions differentes, quoique 
relativement proches, de 1'IMS. 

Parallelement au developpement de 1' architecture IMS, un autre groupe, cree en 2002 et 
nomme OMA (Open Mobile Alliance), s'est implique dans le developpement de 1'IMS 
pour la definition de services plus evolues que ceux prevus par le 3GPP et le 3GPP2. 



Introduction a TIMS 

Cette section presente des generalites qu'il est important d' avoir a 1' esprit avant d'entrer 
dans 1' architecture de 1'IMS. 



Protocoles utilises dans 1'IMS 

Les trois principaux protocoles utilises dans 1'IMS sont les suivants : 

SIP est le protocole federateur de 1' architecture IMS. II est en quelque sorte la glue 
qui permet aux differents composants de communiquer entre eux de maniere homo- 
gene. 

Son choix, par rapport a tout autre protocole de signalisation, n'est pas anodin puisqu'il 
perennise SIP au detriment de H.323, juge trop lourd et trop couteux. II marque ainsi la 
confiance des industriels et du monde de la recherche dans le protocole SIP. 

Bien sur, son utilisation implique celle des protocoles associes, en particulier SDP, pour 
la description des sessions, et RTP/RTCP, pour le transport en temps reel des flux de 
donnees multimedias. 
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Diameter, decrit dans la RFC 3588 de 1'IETF, est un protocole de type AAA (Authentica- 
tion, Authorization, Accounting). Successeur du protocole RADIUS (Remote Authenti- 
cation Dial-In User Service), son nom est un jeu de mots visant a symboliser revolution 
de la technologie puisque le diametre (en anglais diameter) est le double du rayon (en 
anglais radius). II est employe pour la securisation des communications, notamment lors 
de l'enregistrement des utilisateurs et lorsque les profils utilisateur sont transferes d'une 
base de donnees vers les serveurs de traitement (nous decrivons plus loin ces entites). 
II fonctionne en mode client/serveur, done sous la forme de requetes et de reponses. 
Diameter est egalement present dans IPsec et TLS. 

COPS (Common Open Policy Service) est un protocole flexible permettant la mise en 
place de politiques par une entite centrale appelee PDP (Policy Decision Point), qui sont 
appliquees sous formes de regies dans des entites appelees PEP (Policy Enforcement 
Point). COPS sert notamment a permettre aux operateurs de garantir une qualite de 
service dans une architecture IMS. 

Notions de reseau visite et de roaming 

L' architecture IMS s'appuie sur des reseaux d'acces tres etendus. Non seulement il est 
possible d'utiliser de multiples technologies d'acces, mais, en outre, les zones d'acces 
geographiques doivent etre aussi larges que possible dans la vision IMS. Autrement dit, 
le terminal IMS de 1' utilisateur — on parle egalement de UE (User Equipment) — doit 
pouvoir se connecter de partout. 

Un operateur possedant une infrastructure physique forcement limitee, il convient de 
prendre en compte la possibilite d' exploiter des reseaux tiers, e'est-a-dire de permettre a 
un abonne d'un operateur d'utiliser des reseaux d'acces physiques qui appartiennent a 
d'autres operateurs que le sien. 

Pour cela, on introduit le concept de reseau visite : lorsqu'un utilisateur utilise un reseau 
qui n'est pas celui de 1' operateur auquel il a souscrit un contrat de services, on dit que le 
reseau en question est visite. 

La connexion de l'utilisateur a un reseau visite est soumise aux accords qui lient son 
operateur a 1' operateur qui exploite le reseau visite. En effet, pour qu'une connexion soit 
permise, si 1' operateur qui exploite un reseau ne peut pas identifier (et facturer) un utili- 
sateur, il est indispensable qu'il existe des engagements contractuels avec un autre operateur 
(que l'utilisateur devra mentionner lors de sa connexion). 

On parle de roaming pour designer la possibilite qu'a un utilisateur de se connecter a 
un reseau qui n'est pas celui de son operateur. De meme, les accords de roaming decri- 
vent les conditions contractuelles qui lient un operateur, exploitant une base de 
donnees de clients, a un operateur, exploitant un reseau d'acces avec une couverture 
geographique. 
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Le modele a quatre couches de I'architecture IMS 

IMS propose une approche modulaire qui permet de distinguer des niveaux de traitements 
differents. 

Quatre couches (ou « plans ») peuvent etre identifiees, chacune d'elles etant liee a un 
domaine specifique (la figure 16.1 illustre un schema global de I'architecture en couches 
de l'IMS) : 



t^i 








g2^ 



^ 



Serveur d'appli cations Serveur d'applications Serveur d'applications 

SIP IM-SSF OSA-SCS 



'APPLICATIONS/ 



Fourniture de services 




Connectivite de bout en bout 



Figure 16.1 

Architecture de l'IMS 



La couche acces. Elle definit la maniere dont l'utilisateur se connecte au reseau. Parmi 
les reseaux d' acces, on peut citer les plus classiques : GSM (Global System for Mobile 
communications), UMTS (Universal Mobile Telecommunications System), CDMA 
2000 (Code Division Multiple Access 2000), UMA (Unlicensed Mobile Access), 
xDSL (xDigital Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide Intero- 
perability for Microwave Access) et les reseaux fixes, comme Ethernet, ATM, la fibre 
optique et le cable, par exemple. Cette liste non exhaustive est susceptible de contenir 
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n'importe quel reseau d'acces, qu'il soit filaire ou non. Remarquons que les reseaux 
supportes ne s'orientent ni vers IP, ni vers les reseaux cellulaires en particulier, mais 
visent une large etendue de possibilites. 

En regroupant differents types de reseaux d'acces au sein de cette couche, IMS offre 
un niveau d' abstraction a la maniere dont l'utilisateur se connecte au reseau. Cette 
vision est a l'origine de l'idee de convergence des reseaux vers un reseau unique, 
pronee par 1'IMS. Autrement dit, IMS est independant du reseau d'acces, qui n'est 
qu'un element assurant la connectivite de l'utilisateur au reseau coeur. 

• La couche transport. Elle permet la connectivite de bout en bout entre les differents 
interlocuteurs. Alors que la couche d'acces se contente de connecter un utilisateur au 
reseau IMS, la couche transport se charge de l'acheminement des donnees de l'utilisa- 
teur jusqu'a son (ou ses) correspondant(s). Cela comprend le transport de l'information par 
les routeurs et le choix de la route empruntee dans le reseau. C'est le reseau IP qui est 
utilise dans cette couche. 

• La couche controle. Elle assure la gestion et le controle du reseau. Elle est en charge 
de tous les messages de signalisation dans le reseau, permettant d'ouvrir, de maintenir, 
de modifier et de terminer une session entre des utilisateurs. C'est la partie intelligente 
du modele, qui offre toutes les fonctionnalites de gestion des utilisateurs et constitue le 
veritable socle de 1'IMS. Nous la detaillons plus loin, en presentant l'ensemble des 
entites qui s'inscrivent dans cette architecture. 

• La couche application. Elle consiste en la fourniture des services, qu'ils soient 
audio, video ou textuels. Cette couche implemente tous les services que Ton peut 
proposer aux utilisateurs. Elle est la partie la plus ouverte du modele, puisque le 
reseau IMS ne specifie pas les services eux-memes, mais offre une plate-forme de 
deploiement unifiee, simple, rapide, productive et securisee pour la mise en place 
de nouveaux services. Sa description est assez sommaire, mais elle est susceptible 
d'etre enrichie a l'infini, selon les nouveaux services que Ton souhaite apporter et 
toutes les propositions amenees par des developpeurs. On peut, notamment, 
mentionner les applications classiques de presence, de messagerie instantanee et de 
push-to-talk. Nous verrons plus loin les differentes categories de services que 1'IMS 
permet de distinguer. 

Chaque couche est independante, de sorte qu'il est possible, par exemple, d'ajouter libre- 
ment de nouveaux services dans la couche applicative, sans tenir compte du reseau 
d'acces que les utilisateurs ont employe, ni du terminal qu'ils ont utilise. Cela dit, il est 
souhaitable que les serveurs d' applications adaptent leur reponse en fonction de ces criteres : 
par exemple, une page Web ne doit pas contenir les memes informations ni etre formatee 
de la meme maniere selon qu'elle est destinee a etre visualisee sur un ordinateur portable 
ou sur un telephone portable. 
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La couche de transport 

La couche de transport est une couche generique IP. Elle est formee d'un maillage de 
commutateurs et de routeurs qui assurent, dans le reseau IP, le routage des donnees multi- 
medias, a 1' exclusion des informations de signalisation, qui sont a la charge de la couche 
de controle, decrite plus loin. 

Elle dispose en outre de deux sous-systemes particuliers : 

• NASS (Network Attachment Subsystem) pour la configuration du reseau. II permet de 
disposer dans le reseau de 1' equivalent d'un serveur DHCP, afin d'attribuer une adresse 
IP a l'utilisateur, et d'un client, pour les authentifications de l'utilisateur, realisees sur 
son profil. 

• RACS (Ressource Admission Control Subsystem) pour le controle d' admission. II permet 
d'allouer les ressources sollicitees par les applications en effectuant, a la demande, des 
reservations. 

La couche de controle 

La couche de controle est constitute de differentes entites logiques que nous allons 
detailler. 

Toutes ces entites constituent le socle de 1' architecture IMS et, a ce titre, sont indispen- 
sables pour le fonctionnement d'un reseau IMS. Elles sont des entites logiques, ce qui 
signifie que, malgre leur distinction fonctionnelle, rien n'empeche de les implementer 
(toutes ou certaines) au sein d'un meme equipement. 

Ces entites sont les suivantes : 

HSS et SLF 

CSCF (decline en P-CSCF, I-CSCF et S-CSCF) 

MRF (reparti en MRFC et MRFP) 

BGCF 

MGW, MGCF et SGW 

TrGW et IMS-ALG 

Serveur d' applications (SIP, IM-SSF et OSA-SCS) 
Les sections suivantes detaillent chacune d'entre elles. 
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HSS (Home Subscriber Server) : la base de donnees des utilisateurs 

Le serveur HSS (Home Subscriber Server) est une entite centralisee qui stocke une base 
de donnees contenant 1' ensemble des proflls des utilisateurs. II comporte, entre autres et 
pour chaque utilisateur, les informations suivantes : 

• Localisation des terminaux des utilisateurs abonnes. 

• Identite complete des utilisateurs susceptibles d'acceder au reseau IMS. 

• Parametres permettant leur authentiflcation et les informations d'autorisation d'acces. 

• Ensemble des services auxquels ils ont souscrits. 

• Preferences de services (on peut imaginer toutes sortes de preferences, par exemple la 
redirection vers la messagerie d'un utilisateur en fonction de l'heure). 

• Serveur S-CSCF, qui traite les demandes de l'utilisateur (attribue dynamiquement lors 
de la connexion de l'utilisateur). 

Toutes les donnees relatives a un meme compte utilisateur doivent etre stockees sur un 
meme HSS. Neanmoins, lorsque le nombre d' utilisateurs est important, il est possible de 
les repartir au sein de plusieurs HSS. Dans ce cas, il est necessaire de mettre en place une 
entite complementaire, appelee SLF (Subscription Locator Function), qui a pour role de 
determiner le HSS contenant les donnees relatives a un utilisateur. 

Dans la suite, nous nous contenterons de parler d'un serveur HSS, meme s'il peut y en 
avoir plusieurs, auquel cas, il s'agirait d'un serveur SLF qui relaie les requetes vers le 
HSS qui convient. 

Les serveurs HSS et SLF communiquent avec les autres entites du reseau au moyen du 
protocole Diameter. 

CSCF (Call State Control Function) : les trois gestionnaires d'appels 

Les CSCF sont des serveurs de controle de sessions, qui utilisent le protocole de signali- 
sation SIP pour communiquer. Ils sont les organes de traitement des references dans 
1' architecture IMS et realisent les fonctions permettant d'orienter et de controler une 
session. 

Concretement, lorsqu'un utilisateur se connecte, il peut acceder a un reseau qui n'est pas 
celui de l'operateur chez qui il a souscrit un service. II faut done que l'utilisateur 
emprunte le reseau pour assurer sa connectivite, tout en cherchant a se relier a des entites 
appartenant a son operateur, pour avoir acces aux services de son contrat. 

II existe trois types de CSCF, representes a la figure 16.2. Chacun de ces serveurs 
peut se trouver en nombre dans un reseau IMS, notamment pour repondre a la charge 
des demandes. 

Nous detaillons dans les sections qui suivent le role de chacun de ces serveurs. 
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Figure 16.2 

Les serveurs CSCF 



P-CSCF (Proxy-CSCF) 

Le serveur P-CSCF constitue le point d' entree dans le reseau IMS pour tout ce qui 
concerne la signalisation d'une session d'un utilisateur. II est situe dans le reseau auquel 
le terminal se connecte, meme si ce reseau n'est pas celui de l'operateur auquel l'utilisateur 
est abonne. 

Des qu'une requete de signalisation est envoyee depuis un terminal, elle est receptionnee 
par un P-CSCF. Ce dernier est charge de prendre en charge les requetes d'un utilisateur et 
de les rediriger vers les serveurs concernes (c'est-a-dire les serveurs appartenant a 
l'operateur auquel l'utilisateur a souscrit un service). De meme, apres avoir envoye la 
requete de l'utilisateur au serveur concerne, c'est le P-CSCF qui relaie la reponse obte- 
nue vers le terminal. Le P-CSCF est done un intermediaire impose entre le terminal et les 
autres serveurs. 

Dans la pratique, lorsqu'un terminal est connecte au reseau IMS, il initie une etape 
d' activation de contexte PDP lui permettant de negocier les parametres avec lesquels ses 
services vont etre lances. Cette etape est indispensable pour pouvoir ensuite emettre et 
recevoir des requetes SIP. Lors de cette etape, le terminal decouvre l'adresse du serveur 
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P-CSCF. Celui-ci sert a aiguiller chacune des requetes emises par le terminal. Autrement 
dit, le terminal s'adresse au P-CSCF pour lui formuler ses requetes, et c'est le P-CSCF 
qui est charge de les mener a bien. 

Le P-CSCF est determine et attribue pour toute une session, d'une connexion a la 
deconnexion d'un utilisateur. Par contre, il peut changer lors de la session suivante de 
l'utilisateur. 

Le serveur P-CSCF n'est pas necessairement la propriete de l'operateur auquel le client a 
souscrit un service. Au contraire, et c'est tout son interet, il peut etre un intermediaire 
entre le terminal client IMS et les serveurs de l'operateur de l'utilisateur. 

Considerons un utilisateur qui se trouve physiquement dans une region ou son operateur 
ne dispose d'aucune infrastructure pour permettre sa connexion, par exemple a l'etran- 
ger. Dans ce cas, et pour peu que l'operateur de l'utilisateur ait un contrat avec l'opera- 
teur qui gere cette region, l'utilisateur peut quand meme se connecter en utilisant l'infras- 
tructure du reseau visite, materialise par le P-CSCF de l'operateur de la region. 
Le terminal est dans ce cas « visiteur » dans le P-CSCF qu'il sollicite. 

Outre sa necessite physique, le P-CSCF facilite les facturations entre operateurs. Bien 
sur, le P-CSCF peut aussi etre celui de l'operateur auquel l'utilisateur a souscrit un abon- 
nement. 

Ainsi, dans tous les cas, le terminal possede un interlocuteur virtuel privilegie, auquel il 
delegue le soin d'aiguiller ses demandes. De cette maniere, le terminal n'a qu'une vision 
minimale des serveurs du reseau IMS, et c'est au serveur P-CSCF que revient la charge 
de localiser et contacter les autres entites. 

Le reseau de signalisation est de la sorte protege par le P-CSCF, qui agit comme un 
garde-barriere. II peut meme avoir les fonctionnalites suivantes : 

• Controle de syntaxe des requetes SIP. 

• Controle d'integrite des donnees. 

• Controle d' admission en refusant des appels lorsque le reseau est trop charge, arm de 
ne pas degrader la qualite des communications existantes. 

A ce titre, le role du P-CSCF est comparable a celui que joue le proxy SIP dans l'archi- 
tecture SIP. 

Le P-CSCF doit egalement permettre l'aboutissement des appels d'urgence. De plus, il 
est aussi responsable de la gestion de la qualite de service pour l'utilisateur. En ce 
sens, il agit comme le PEP d'une architecture de controle COPS. 

Outre sa fonctionnalite d' intermediaire dans l'acheminement des methodes SIP entre le 
terminal de l'utilisateur et le serveur approprie, le P-CSCF offre des fonctionnalites de 
compression/decompression des messages SIP, afin de reduire le temps d'etablissement 
d'une connexion. 

Le terminal IMS a la possibilite de compresser ses donnees, ce qui permet de les trans- 
mettre plus rapidement au P-CSCF qui les decompresse avant de les transmettre aux 
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entites sollicitees. C'est d'autant plus utile que les reseaux radio (utilises le plus souvent 
dans la couche d'acces) ont generalement une bande passante reduite. L'objectif de la 
compression n'est pas vraiment de ne pas gaspiller la bande passante, mais plutot sa 
consequence immediate, qui est d'accelerer la transmission du message. 

I-CSCF (Interrogating-CSCF) 

Le serveur I-CSCF constitue, pour une session d'un utilisateur, le point d'entree dans le 
reseau de l'operateur auquel l'utilisateur a souscrit un contrat de service. Par exemple, si 
un utilisateur est dans un reseau qui n'appartient pas a son operateur, il peut emprunter ce 
reseau en utilisant un intermediate (le serveur P-CSCF), lequel redirige ses requetes vers 
une entite du reseau de son operateur (le serveur I-CSCF). Cette redirection est realisee, 
meme si l'utilisateur est dans le reseau de son operateur, mais, dans ce cas, son interet est 
moindre. 

Le serveur I-CSCF n'est que le point d'entree du reseau d'un operateur. II ne realise pas 
de traitements pour repondre aux requetes des utilisateurs, mais se contente de designer 
des entites qui le font (les serveurs S-CSCF, decrits dans la section qui suit). Le role du 
I-CSCF est done essentiellement de masquer le reseau de l'operateur en fournissant un 
simple point d'entree et d'aiguiller les requetes de ses abonnes vers les serveurs 
adequats. 

Concretement, c'est grace au P-CSCF que le serveur I-CSCF peut etre sollicite : l'utili- 
sateur, qui connait uniquement le domaine de son operateur, envoie cette information 
vers le P-CSCF auquel il est connecte. Avec le domaine mentionne par l'utilisateur, le 
P-CSCF peut effectuer une requete DNS pour determiner l'adresse IP du serveur I-CSCF 
et peut alors contacter le serveur I-CSCF. 

Le I-CSCF assure egalement des fonctionnalites de facturation et de pare-feu pour proteger 
le reseau de l'operateur puisqu'il se place a l'entree de celui-ci. 

Le I-CSCF peut etre relie a d'autres I-CSCF appartenant a d'autres operateurs, afln de 
permettre les communications entre les utilisateurs d' operateurs distincts. 

S-CSCF (Serving-CSCF) 

Le serveur S-CSCF doit assurer la gestion de la session d'un utilisateur. Plus precise- 
ment, tous les messages de signalisation SIP emis ou re^us par le terminal IMS de l'utili- 
sateur traverseront le S-CSCF attribue a la session du terminal et seront traites par ce 
dernier. 

Le serveur S-CSCF est determine grace au serveur I-CSCF (et toujours par l'interme- 
diaire du P-CSCF) : apres que le P-CSCF a contacte le I-CSCF, ce dernier assigne un 
S-CSCF pour servir l'utilisateur, en fonction des S-CSCF disponibles, afln de repartir au 
mieux la charge supportee par chacun d' entre eux. II en informe alors le P-CSCF, de 
maniere que ce dernier puisse ulterieurement s'adresser directement au S-CSCF. Paral- 
lelement, le S-CSCF enregistre dans le HSS la position de l'abonne dans le reseau et 
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indique au HSS son adresse, afin qu'une entite cherchant a joindre l'abonne sache a quel 
S-CSCFs'adresser. 

Une fois designe pour servir la session d'un utilisateur, le premier role du S-CSCF est de 
recuperer aupres de la base HSS, et avec le protocole Diameter, l'ensemble des parame- 
tres de profll de l'utilisateur pour l'enregistrer, 1' authentifler et verifier ses droits d'acces. 
De plus, il met a jour, dans cette meme base HSS, l'etat courant des sessions dont il a la 
charge, afin de pouvoir localiser l'utilisateur dans ses deplacements (en sauvegardant leur 
adresse IP), modifier les preferences de ce dernier, mais aussi avoir l'historique de ses 
communications (utile a la facturation, par exemple). 

Remarquons que le terminal de l'utilisateur lui-meme ne connait jamais l'adresse du 
I-CSCF, ni celle du S-CSCF. Ces informations sont masquees et ne sont connues que 
du P-CSCF qui sollicite les serveurs concernes pour le terminal. 

Le role du serveur P-CSCF doit etre precise puisque lui aussi fait transiter tous les messa- 
ges SIP emis ou regus par le terminal : en fait, le serveur P-CSCF ne fait essentiellement 
que relay er tous les messages qui lui parviennent vers le I-CSCF ou le S-CSCF, il n'est 
done qu'un intermediate. Au contraire, le S-CSCF est responsable des traitements a 
realiser pour l'utilisateur. 

Le S-CSCF est de plus 1' entite chargee d'effectuer le routage des appels. En particulier, 
si l'adresse de destination n'est pas une adresse SIP, mais, par exemple, un numero de 
telephone standard, le serveur S-CSCF fournit les fonctionnalites de conversion pour 
joindre les passerelles telephoniques. 

Enfln, le S-CSCF est charge d'effectuer l'interaction avec les serveurs d' applications en 
commutant les requetes de l'utilisateur vers les serveurs adequats. 

Tout comme le P-CSCF, le S-CSCF n'est pas determine statiquement pour servir un utili- 
sateur, mais lorsqu'une session demarre, le S-CSCF choisi ne change pas tout au long de 
la session de l'utilisateur. En particulier, lors de la phase d'enregistrement, le S-CSCF 
stocke temporairement les informations relatives au profll de l'utilisateur (qu'il aura 
recupere aupres du HSS) de maniere a traiter plus rapidement et directement les droits et 
preferences de ce dernier. 

MRF (Multimedia Resource Function) : pour la gestion des conferences 

L' entite MRF (Multimedia Resource Function) permet d'etablir un pont de conference 
entre les utilisateurs d'un reseau IMS. Son role est de gerer la signalisation de et vers tous 
les utilisateurs d'une conference, en offrant des facilites d' exploitation, comme la selec- 
tion des types de flux — par exemple, si sa bande passante est faible, il est possible de 
demander uniquement le flux audio sur son poste, tandis que d'autres utilisateurs dispo- 
seront de la video — et la conversion des formats de codecs — il est possible d'utiliser 
des codecs differents pour chaque utilisateur, le MRF adaptant chaque flux aux exigences 
de chacun. 
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Le MRF a un fonctionnement semblable a celui de l'entite MCU (Multipoint Control 
Unit), que nous avons introduite au chapitre 3, consacre a H.323, si ce n'est qu'il mani- 
pule une signalisation SIP. 

Comme ce dernier, le MRF se decompose en deux entites logiques : 

• MRFC (Multimedia Resource Function Controller) : pour la partie signalisation, et 
plus precisement la negotiation des parametres sollicites par chaque utilisateur pour la 
mise en ceuvre de la conference. 

• MRFP (Multimedia Resource Function Processor) : pour la partie traitement des flux 
de donnees, c'est-a-dire l'application des demandes formulees par l'utilisateur dans les 
flux. 

BGCF (Breakout Gateway Control Function) : pour la liaison 
avec le reseau RTC 

BGCF (Breakout Gateway Control Function) est un serveur qui communique en utilisant 
le protocole SIP. II sert a preciser le routage des appels inities par des terminaux IMS vers 
des terminaux fonctionnant en mode commutation de circuits (reseaux filaires traditionnels 
ou reseau GSM, par exemple). 

En considerant qu'un terminal IMS cherche a joindre un correspondant dans le reseau 
RTC, deux cas peuvent se produire, selon la compatibility de l'appareil : 

• Si l'appareil qui se connecte est compatible avec le reseau du correspondant qu'il 
cherche a joindre, le BGCF se charge de mettre en relation les deux entites. 

• Sinon, comme l'appareil n'est pas compatible avec le reseau du correspondant qu'il 
cherche a joindre, le BGCF indique des passerelles specifiques (de type MGCF, 
presentees plus loin) responsables d'effectuer la liaison et auxquelles le BGCF relaie 
toute la signalisation qu'il re^oit. 

IMS-MGW, MGCF et SGW : pour I'interfonctionnement avec le reseau 
RTC 

Avec 1'IMS, il est indispensable d'etre ouvert aux reseaux les plus classiques, ce qui 
inclut bien evidemment le reseau commute RTC. 

Pour ce faire, les trois entites illustrees a la figure 16.3 sont introduites. II s'agit de 1'IMS- 
MGW, du MGCF et du SGW. 

Ces trois entites se repartissent sur deux plans : un plan de donnees (couche transport) et 
un plan de signalisation (couche controle). Nous allons decrire chacune d'elles. 
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Figure 16.3 

Interfonctionnement avec le reseau RTC 



La passerelle de flux multimedia IMS-MGW (IMS-Media Gateway) 

Cette entite assure le transport des flux de donnees d'un reseau IP vers un reseau RTC, en 
effectuant la liaison entre un terminal du cote IP et son correspondant du cote RTC, avec 
le transcodage correspondant (d'un flux RTP vers un flux TDM). C'est done une passe- 
relle de flux de donnees multimedias qui convertit les flux de donnees multimedias codes 
en RTP (dans le reseau IP) en flux de donnees multimedias codes en TDM (dans le reseau 
RTC). Elle se situe sur la couche transport. 

Generalement, cette passerelle possede des fonctionnalites complementaires de traitement 
du media, comme la suppression d'echo. 

Le contrdleur de passerelle MGCF (Media Gateway Control Function) 

Cette entite, qui agit au niveau de la signalisation, assure le passage du mode paquet (IP) 
au mode circuit (RTC) en ouvrant, maintenant et fermant des connexions entre les 
reseaux IP et RTC et en assurant la conversion des protocoles de signalisation propres a 
ses reseaux. 

Le serveur doit done convertir un message SIP qui provient du reseau IP en un message 
ISUP dans le reseau RTC. Le message ISUP correspondant sera remis a 1' entite SGW, 
presentee plus loin. 

Le MGCF determine le transcodage des flux de donnees et controle la passerelle de flux 
multimedias IMS-MGW. La communication entre le serveur MGCF et le serveur 
IMS-MGW se fait au moyen du protocole de signalisation MEGACO/H.248. 
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Le serveur MGCF doit egalement informer le serveur S-CSCF des messages de signali- 
sation qu'il genere pour que ce dernier connaisse les communications et operations en 
cours. 

La passerelle de signalisation SGW (Signaling Gateway) 

Comme la precedente, cette entite concerne la partie signalisation. Sa fonction est de 
transporter, un message de signalisation ISUP d'un transport SS7 vers SIGTRAN. 

Le serveur SGW joue le role de passerelle pour la signalisation ISUP. II est en contact 
avec 1' entite MGCF qui se charge de remplacer la signalisation ISUP en signalisation 
SIP. 

TrGW et IMS-ALG : pour le support transparent des adresses IPv4 

D'IPv4 a IPv6 

Le protocole IPv6 est recommande pour 1'IMS. En effet, si Ton considere que chaque 
terminal telephonique est, potentiellement, un client IMS, il faut fournir une adresse IP a 
chacun d'entre eux ; or le nombre d' adresses IPv4 est insufflsant pour couvrir le besoin 
d'adressage de tous les terminaux telephoniques. 

IPv4 dispose d'un adressage sur 32 bits, ce qui laisse 2 32 adresses disponibles au maxi- 
mum (sur les 32 bits, certains sont reserves a des usages ou distinctions specifiques, tels 
que 1' adressage prive ou le broadcast), soit environ 4 milliards d' adresses IP. De plus, de 
nombreux utilisateurs disposent de plusieurs terminaux IP (un ordinateur personnel, un 
autre professionnel, un telephone portable personnel, un autre fixe, etc.), soit autant 
d' adresses IP potentiellement necessaires. 

Face a cette penurie d'adresses IPv4, il sera done necessaire de s'orienter vers IPv6, qui 
offrira 128 bits pour 1' adressage, soit environ 2 128 adresses disponibles et un nombre 
relativement large de terminaux pouvant etre simultanement connectes et compatibles 
avec le protocole IP. 

Neanmoins, si la version 6 du protocole IP existe depuis 1995 et que sa maturite est rare- 
ment contestee, son exploitation dans les reseaux IP demeure, encore aujourd'hui, parti- 
culierement lente, voire incertaine. 

Une des raisons a cela est l'investissement a realiser pour les operateurs afin de rendre 
leur infrastructure compatible avec le nouveau protocole. En outre, 1' absence de reel 
besoin immediat de cette technologie freine son evolution. Seuls quelques efforts ponc- 
tuels ont ete inities pour oeuvrer a l'essor d'IPv6. Par exemple, l'autorite mondiale de 
regulation des adresses dans l'lnternet, 1' ICANN (Internet Corporation for Assigned 
Names and Numbers) a attendu l'annee 2008 pour rendre compatibles avec IPv6 six de 
ses treize serveurs DNS (Domain Name Server). En revanche, l'operateur fran^ais Free a 
deploye la technologie dans son reseau pour tous ces abonnes. 
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IMS pousse en faveur du protocole IPv6, car si la penurie d'adresses IP pour les ordina- 
teurs n'est pas encore d'actualite, il est certain que le deploiement d'un reseau IMS va 
rapidement engendrer un grand besoin d'adresses IP afm d'y connecter tous les terminaux 
telephoniques. 

Compatibilite assuree avec des passerelles IPv4-IPv6 

Le systeme IMS doit considerer a la fois un reseau IPv6, inevitablement attendu, et un 
reseau IPv4 existant. Pour permettre une evolution en douceur vers la version 6, IMS 
assure la compatibilite avec IPv4 et met en ceuvre des entites specialement dediees aux 
communications entre des stations qui communiquent avec IPv4 et des stations qui 
communiquent avec IPv6. De cette maniere, le reseau IMS se charge d'effectuer la tran- 
sition entre les deux protocoles de maniere transparente. 

Pour cela, les deux entites illustrees a la figure 16.4 sont introduites : TrGW (TRansition 
GateWay) et IMS-ALG (IMS -Application Layer Gateway). 



Translation des flux de signalisation (SIP et SDP) " 




s v^ Translation des flux de donnees(RTP et RTCP) S 
** ^ ^ entre les reseaux IPv4 et IPv6 ^"' 



Figure 16.4 

Les serveurs IMS-ALG et TrGW 



Lorsqu'une station IPv6 communique avec une station IPv4, cette derniere n'est, a 
priori, pas capable de comprendre le message qui lui parvient. L'idee consiste a mettre en 
place une entite intermediaire entre ces deux stations afln d'effectuer la conversion du 
protocole IP entre les versions 4 et 6. 

Comme les messages qu'une station peut envoyer a une autre sont de deux types (flux 
de donnees et signalisation), deux entites fonctionnelles sont devolues a ces taches : la 
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passerelle TrGW, qui effectue la translation d'adresses sur les flux de donnees, et 
lapasserelle IMS-ALG, qui effectue la translation d'adresses au niveau de la signa- 
lisation. 

Autrement dit, la passerelle TrGW agit sur les messages de donnees encapsules par RTP 
(et les retours RTCP), tandis que la passerelle IMS-ALG agit sur les messages de signa- 
lisation SDP et SIR 



Les serveurs d'applications 

Les serveurs d'applications — souvent abreges en AS (Application Server) — sont 
des entites SIP fournissant different types de services aux utilisateurs. lis 
sont connectes au serveur S-CSCF, qui joue 1' intermediate entre l'utilisateur et les 
services. 

On distingue trois grandes families de serveurs d'applications : SIP AS (SIP Application 
Server), IM-SSF (IP Multimedia-Service Switching Function) et OSA-SCS (Open 
Service Access-Service Capability Server). 

SIP AS (SIP Application Server) 

Ces serveurs permettent 1' execution des services nativement implementes pour fonctionner 
avec SIP. 

Les services les plus classiques (service de presence, push-to-talk, messagerie instantanee, 
etc.) sont generalement implementes au sein de ces serveurs. 

IM-SSF (IP Multimedia-Service Switching Function) 

Pour permettre la mobilite de l'abonne tout en lui garantissant la fourniture de ses 
services — meme s'il se trouve dans une infrastructure qui n'appartient pas a son 
operateur de services (on parle de roaming pour designer la connexion d'un utilisateur 
a un reseau qui n'est pas celui de son operateur) — , il est necessaire d' avoir une 
passerelle, appelee IM-SSF, afin de connecter l'abonne au serveur d'applications de 
son operateur. 

La communication entre le serveur IM-SSF et le serveur d'applications de 1' operateur 
distant s'effectue au moyen d'une technologie de signalisation decrivant l'interfa^age 
avec les applications. Cette signalisation s'appelle INAP (Intelligent Network Applica- 
tion Part) dans le cadre des reseaux fixes et CAMEL (Customized Applications for 
Mobile network Enhanced Logic) dans celui des reseaux sans fil GSM. 

Les communications entre le serveur IM-SSF et les serveurs distants utilisent le proto- 
cole CAP (Camel Application Part), specifie par le 3GPP sous la reference TS 29.278, en 
Janvier 2005. 



L'architecture IMS 



Chapitre 16 

IM-SSF permet ainsi d'acceder a des services distants en realisant 1' interface entre, d'un 
cote, le serveur S-CSCF (qui communique avec le protocole SIP) et, de 1' autre cote, des 
serveurs distants (en communiquant avec le protocole CAP). 

OSA-SCS (Open Service Access-Service Capability Server) 

Ces serveurs fournissent le moyen d'interagir avec les serveurs d' applications OS A. 
OS A a ete defini par le 3GPP et l'ETSI comme une architecture de gestion des services 
dans un reseau telephonique de troisieme generation. Son objectif est de proposer une 
vision tres abstraite du reseau, n'imposant aucune architecture en particulier et s'adaptant 
facilement, quelle que soit l'architecture consideree. 

Grace a OSA, les developpeurs peuvent concevoir des applications sans prendre en 
compte les specificites architecturales du reseau considere, ce qui facilite le processus de 
deploiement et evite d' avoir a repenser plusieurs fois les memes applications selon les 
reseaux cibles. 

Pour cela, OSA fournit une API qui facilite le developpement des services. Cette API, 
ouverte, librement telechargeable et independante des technologies utilisees, a ete 
nommee OSA Parlay. Elle tire son nom du consortium Parlay (http://www.parlay.org), qui 
regroupe plusieurs industriels, tels que France Telecom, IBM, Telcordia, Sprint ou Ericsson, 
et qui a developpe les API, avant de les soumettre au 3GPP pour normalisation. Le 3GPP 
y fait reference, de maniere plus neutre, sous le nom d' API OSA (document de Janvier 
2005, reference TS 29.278). Cette souplesse dans le mode de developpement des applica- 
tions, ajoutee a la possibilite d'interfa^age avec ces applications, sont accessibles avec 
1'IMS grace au serveur OSA-SCS. 

Ainsi, OSA-SCS permet d'acceder a des services generiques en realisant l'interface 
entre, d'un cote, le serveur S-CSCF (qui communique avec le protocole SIP) et, de 
1' autre cote, des serveurs implementant des applications pensees sur le modele generique 
de l'architecture OSA (en communiquant avec les API OSA). Cela permet l'emergence 
de services tiers et favorise le developpement de nouveaux services. 

Notons pour finir la notion d' applications dites enabler, c'est-a-dire definissant un 
composant de base standardise realisant une fonction precise et qui est facilement reutili- 
sable et exploitable pour construire des services plus sophistiques. Les services de 
presence, de localisation ou de messagerie instantanee (SMS ou MMS notamment) sont 
des exemples d' applications enabler. 

Les identites IMS 

Le reseau IMS reprend la notion d' identites publique et privee, qui est propre aux 
reseaux a commutation de circuits des telecoms. 

L'identite publique d'un utilisateur designe un URI (SIP ou de type telephonique) affecte 
publiquement a l'utilisateur et utilise par les correspondants de ce dernier pour le 
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designer, et done le joindre. Dans la terminologie telecoms, ce concept est l'equivalent 
du MSISDN (Mobile Subscriber ISDN Number). 

Par exemple, si un utilisateur dispose d'une adresse professionnelle et d'une adresse 
privee, il dispose de deux identites publiques correspondant a chacune de ses adresses. 
De plus, meme si l'utilisateur ne dispose que d'une adresse privee, celle-ci peut se 
presenter a la fois sous la forme d'un URI SIP et d'un URI telephonique. La premiere 
forme (au format sip:identifiant@ operateur) est adaptee au protocole SIP qu'exploite 
TIMS et est done preferable de maniere generale. La seconde (au format 
tel: +952955295) est indispensable pour etre joignable a partir de terminaux non-IMS, 
qui ne disposent que de chiffres pour joindre leurs correspondants et ne sont joignables 
que par un numero d'appel. 

L'identite privee d'un utilisateur designe un identiflant au format NAI (Network 
Access Identifier) qui est de type identifiant@ operateur. Elle est affectee secretement 
a l'utilisateur et est utilisee par 1' operateur pour designer ce dernier. Dans la termino- 
logie telecoms, ce concept est l'equivalent de 1'IMSI (International Mobile Subscriber 
Identifier). 

Par exemple, si un utilisateur dispose de plusieurs identites publiques, il peut toutes les 
gerer a partir d'un compte unique (d'une identite privee) et done d'un terminal unique, 
lequel recevra les appels destines a l'utilisateur, et ce quelle que soit l'identite publique 
avec laquelle les appels sont adresses. L'identite privee est avant tout utile pour permettre 
1' identification et 1' authentication de l'abonne par 1' operateur. 

De la meme maniere qu'une identite privee peut etre liee a plusieurs identites publiques, 
une identite publique peut etre liee a plusieurs identites privees. Par exemple, conside- 
rons un utilisateur qui dispose de deux terminaux IMS, le premier etant professionnel, le 
second prive, et de deux identites publiques, la aussi, une professionnelle et 1' autre 
privee. Chacun des terminaux de cet utilisateur sera configure avec une identite 
privee. II peut decider de ne recevoir, sur le premier terminal, que les appels profession- 
als (e'est-a-dire lies a son profll public professionnel), tandis que, sur le second termi- 
nal, il decidera de recevoir tous les appels (e'est-a-dire a la fois ceux lies a son compte 
professionnel et ceux lies a son compte personnel). 

Ainsi certaines identites privees sont-elles liees a plusieurs identites publiques, et certaines 
identites publiques a plusieurs identites privees. 

Gestionnaire d'identites 

Les terminaux IMS sont identifies par la presence d'une carte a puce appelee UICC 
(Universal Integrated Circuit Card), qui comporte un ensemble d' informations d'iden- 
tiflcation et de personnalisation, et sans laquelle seuls les appels d'urgences sont 
possibles. 
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L' interface de communication entre la carte UICC et le terminal est standardisee, mais la 
carte UICC est generique et peut comporter toutes sortes d' applications, notamment les 
applications classiques suivantes : 

• SIM (Subscriber Identity Module). Cette application specifiee dans les documents 
3GPP TS 11.11 et 3GPP TS 51.01 1 est bien connue pour son usage massif et genera- 
lise dans les reseaux GSM. En fait, le 3GPP ne fait ici que reprendre une application 
existante et formaliser son usage. Elle fournit, en particulier, des informations relatives 
au reseau de l'utilisateur, son identite, ses preferences, ses parametres d'authentiflca- 
tion et de cryptage, ainsi que des informations de stockage (typiquement la sauvegarde 
de SMS ou de son carnet d'adresses). 

• USIM (Universal Subscriber Identity Module). Cette application specifiee dans le 
document 3GPP TS 31.102 est indispensable pour operer la connexion d'un terminal 
dans un reseau de troisieme generation (UMTS, par exemple). La nature des informa- 
tions stockees est semblable a celle de la SIM, mais la maniere dont 1' information est 
stockee differe. 

• ISIM (IP multimedia Services Identity Module). Cette application specifiee dans le 
document 3GPP TS 31.103 stocke notamment les identites publiques et privees d'un 
utilisateur, le domaine de l'utilisateur (c'est-a-dire le reseau appartenant a son opera- 
teur) et une cle secrete utilisee pour des besoins de securite et d'authentiflcation. Ces 
informations ne sont accessibles qu'en lecture seule, ce qui previent toute modification 
par l'utilisateur. C'est la forme la plus adaptee pour gerer l'ensemble des parametres 
de l'utilisateur dans un reseau IMS. 

Ces trois applications ne sont evidemment pas les seules. Meme si elles peuvent contenir 
des informations redondantes, elles peuvent etre utilisees en meme temps par le terminal 
pour fournir plusieurs de ces donnees enregistrees, selon les connexions (SIM pour les 
reseaux GSM, USIM pour les reseaux UMTS, etc.). 

Par contre, il est indispensable de disposer au moins de 1' application ISIM ou USIM pour 
se connecter dans un reseau IMS (le niveau de securite de SIM est insufflsant pour etre 
possible avec IMS) du 3GPP. En ce qui concerne la version IMS du 3GPP2, la notion 
d'UICC est absente, mais ces memes applications USIM et ISIM peuvent etre fournies 
comme une configuration du terminal de l'utilisateur. 

Les extensions du protocole SIP pour IMS 

IMS reprends le protocole SIP dans sa syntaxe et dans son fonctionnement. Neanmoins, 
il definit un ensemble d' extensions supplemental dans les en-tetes du protocole SIP 
pour repondre a quelques besoins specifiques. Ces extensions sont optionnelles pour le 
protocole SIP ; elles sont prefixees par la lettre P pour indiquer qu' elles sont privees (en 
anglais private), suivie d'un tiret. 
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Elles adoptent la meme syntaxe que les en-tetes conventionnels, a savoir le format 
suivant : 

nom_en_tete:valeur_en_tete 

Le tableau 16.1 recapitule les en-tetes les plus utilises. 

Tableau 16.1 - En-tetes SIP supplementaires pour TIMS 

Nom de l'en-tete Description 



P-Asserted-ldentity 



P-Preferred-ldentity 
P-Called-Party-ID 

P-Access-Network-lnfo 
P-Visited-Network-ID 

P-Associated-URI 



P-Charging-Function- 
Addresses 



P-Charging-Vector 



Cet en-tete permet aux entites reseau (typiquement le P-CSCF) de preciser I'identite publique d'un 
utilisateur appelant. II est utilise par une entite du reseau qui aura prealablement identifie I'utilisateur 
(ou bien qui est une entite de confiance), ce qui rend I'identite certaine. 
L'en-tete specifie a sa suite un ou deux URI. S'il y a un seul URI, il est au format SIP ou SIPS (even- 
tuellement precede du nom de I'utilisateur a qui I'URI appartient) ou bien determine un numero de 
telephone. S'il y a deux URI, le premier est necessairement au format SIP ou SIPS, et le second 
necessairement au format telephonique. On aura par exemple : 
P-Asserted-ldentity : "Hanna"<sip : HannaM@nina.com> 
tel : +908070605 

Cet en-tete est specifie par le terminal appelant (User Agent Client) et permet aux entites reseau 
(typiquement le P-CSCF) de connaitre I'identite publique que prefere utiliser un utilisateur appelant. 
II peut y avoir une ou deux valeurs de ce type, de la meme maniere que pour l'en-tete precedent 
P-Asserted-ldentity. 

Cet en-tete permet a I'utilisateur appele de savoir avec quelle identite publique I'appelant I'a contacte. 
Par exemple, un utilisateur peut etre joignable par son adresse professionnelle et par son adresse 
privee. Ce champ d'en-tete lui permet de savoir laquelle de ses adresses a ete utilisee, de maniere 
a pouvoir personnaliser sa gestion (sonnerie particuliere, envoi en messagerie, etc.). L'en-tete est 
generalement ajoute lors de renvoi d'une requete d'invitation (INVITE) par un serveur SIP. 

Cet en-tete permet au terminal IMS de donner des informations sur le reseau qu'il utilise, par exemple 
« IEEE-802.1 1 b », si I'utilisateur se connecte sur un reseau Wi-Fi a la norme 802.1 1 b. 

Cet en-tete permet aux entites du reseau appartenant a I'operateur de I'abonne (typiquement le 
S-CSCF) de connaitre les reseaux que son abonne utilise. Cette information est essentielle pour 
que I'abonne puisse se connecter au reseau qu'il visite : lorsque le reseau de son operateur va 
connaitre le reseau que I'abonne est en train d'utiliser, il va permettre ou non (selon que les opera- 
teurs ont un accord de roaming entre eux) la connexion de I'abonne. 

Cet en-tete permet aux entites du reseau appartenant a I'operateur de I'abonne (typiquement le serveur 
S-CSCF) de retourner I'ensemble des adresses (ou URI) associees a I'identite publique de I'utilisateur. 
On trouve cet en-tete dans la reponse 200 OK a une requete d'enregistrement (REGISTER). 

Cet en-tete permet de determiner les adresses de I'entite chargee de la facturation des abonnes. 
Ajoute par un serveur SIP, il est supporte a la fois comme un champ de requete et comme un champ 
de reponse. Une seule instance de ce champ est toleree. De plus, deux niveaux de facturation sont 
distingues : CCF (Charging Collection Function) pour les couts hors connexion (par exemple une 
carte de connexion prepayee) et ECF (Event Collection Function) pour les couts pendant la connexion 
(par exemple une connexion payee a la duree). 

Cet en-tete permet de mettre en relation des informations de tarification concernant un utilisateur. 
Typiquement, en accedant a un service, un serveur va prendre en charge la tarification, mais comme 
la session peut solliciter d'autres services, d'autres serveurs de facturation peuvent etre exploites, et 
il est necessaire de les regrouper (dans ce que Ton appellera un vecteur de facturation) pour simplifier 
I'offre a I'utilisateur et lui fournir une facture unique. 
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Ces en-tetes sont dermis dans les RFC 3325 (pour les en-tetes P-Asserted-Identity et 
P -Preferred-Identity) et 3455 (pour tous les autres en-tetes) de 1'IETF. 

Les commandes Diameter 

Le protocole Diameter est utilise dans TIMS pour 1' authentication, l'autorisation et la 
journalisation des activites de l'utilisateur (AAA, pour Authentication, Authorization, 
Accouting). 

Specifie dans la RFC 3588 de 1'IETF, il normalise un certain nombre de commandes pour 
permettre son utilisation. 

Le tableau 16.2 detaille la liste des commandes qui sont definies sur l'interface de 
commutation nommee Cx, qui est l'interface de communication la plus utilisee, entre la 
base de donnees HSS et les serveurs I-CSCF et S-CSCF. 



Tableau 16.2 - Commandes sur l'interface Cx 



Norn de la commande Abrege 

User-Authorization-Request UAR 

User-Authorization-Answer UAA 

Server-Assignment-Request SAR 

Server-Assignment-Answer SAA 

Location-Info-Request LIR 

Location-Info-Answer LIA 

Multimedia-Auth-Request MAR 



Code 
numerique 

300 
300 



301 




301 



302 



302 



303 



Description 



Requete d'enregistrement de l'utilisateur, emise du l-CSCF vers 
le HSS. 

Retourne soit le serveur S-CSCF deja en charge de la session 
de l'utilisateur, soit la liste des S-CSCF disponibles, soit un mes- 
sage interdisant la communication de l'utilisateur (si son reseau 
d'acces ne beneficie pas d'accord de roaming par exemple). 

Une fois que I'authentification s'est deroulee avec succes, le ser- 
veur S-CSCF informe le HSS que l'utilisateur est bien enregistre 
au reseau IMS. Cette meme requete est egalement utilisee lors- 
que l'utilisateur n'est plus connecte afin de desassocier I'adresse 
du S-CSCF dans la base HSS. 

En retour a la validation d'authentification, le HSS note que l'uti- 
lisateur devient joignable et fournit au S-CSCF le profil complet 
de l'utilisateur qui servira a identifier precisement les services et 
les preferences de l'utilisateur sans plus solliciter le HSS. 

Pour mettre en relation deux utilisateurs, il faut d'abord que 
I'appelant localise le serveur S-CSCF qui est en charge de la 
session de I'appele. Cette demande du l-CSCF aupres du HSS 
permet de determiner I'adresse SIP du serveur S-CSCF en 
charge de la session du terminal que Ton cherche a contacter. 

Cette reponse est fournie par le HSS au l-CSCF et indique la 
localisation du serveur S-CSCF de l'utilisateur que Ton veut 
contacter (s'il est connecte au reseau). 

Lorsqu'un serveur S-CSCF a ete designe par le l-CSCF pour 
gerer la session d'un utilisateur, il demande au HSS d'associer 
son adresse dans le profil de l'utilisateur. Cette association per- 
mettra a tout autre entite voulant contacter l'utilisateur de 
s'adresser d'abord au S-CSCF designe. 
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Tableau 16.2 - Commandes sur I'interface Cx (suite) 



Norn de la commande 


Abrege 


Code 
numerique 


Description 


Multimedia-Auth-Answer 


MAA 


303 


Le HSS confirme I'association du S-CSCF a la session d'un uti- 
lisateur, et fourni egalement au S-CSCF les informations qui 
permettront d'authentifier I'utilisateur. 


Registration-Terminal- 
Request 


RTR 


304 


A n'importe quel moment, la base HSS peut demander au 
S-CSCF de deconnecter I'utilisateur avec cette requete (a des 
fins administratives notamment). 


Registration-Terminal- 
Answer 


RTA 


304 


Le serveur S-CSCF confirme au HSS qu'il a pris en compte la 
demande et enverra aux entites concernes (P-CSCF et terminal) 
une requete SIP de NOTIFY pour les en informer. 


Push-Profile-Request 


PPR 


305 


Si le profil d'un utilisateur a ete modifie (avec de nouveaux ser- 
vices dynamiquement ajoutes, par exemple), la base HSS peut 
effectuer cette requete aupres du S-CSCF afin de mettre a jour 
les donnees de profil stockees sur ce dernier. 


Push-Profile-Answer 


PPA 


305 


Le serveur S-CSCF repond a la requete de mise a jour de profil 
d'un utilisateur. 



La section suivante donne des exemples d'utilisation de ces requetes. 



Communications avec IMS 

Le protocole SIP est utilise pour l'etablissement, la gestion et la terminaison des 
sessions. Les messages sont done semblables a ceux qui ont ete decrit dans le chapitre sur 
SIP, a quelques extensions pres. 

Nous allons voir comment les messages SIP sont envoyes dans deux cas d' application 
classique : 

• l'enregistrement d'un terminal dans le reseau ; 

• la mise en relation de deux utilisateurs. 



Enregistrement d'un terminal dans le reseau 

L'enregistrement d'un utilisateur dans le reseau est la premiere action realisee par un 
terminal, des sa mise en route. Elle est indispensable puisqu'elle permet a la fois d'appeler 
et d'etre joignable par ses correspondants. 

La methode associee a cette fonctionnalite est registrer, du protocole de signalisation 
SIP. Nous allons detailler le processus mis en oeuvre avec SIP, qui differe avec 1'IMS du 
fait de son architecture particuliere. 
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La figure 16.5 illustre les etapes temporelles liees au scenario d'enregistrement. Nous 
allons considerer que Tenregistrement s'effectue avec succes. 



Terminal I MS P-CSCF 



i 



l-CSCF HSS 



S-CSCF 

§ 



REGISTER 



401 Unauthorized 
REGISTER 



200 OK 



REGISTER 



401 Unauthorized 
REGISTER 



200 OK 



DIAMETER UAR 

k DIAMETER 'iJAA 

REGISTER 



DIAMETERJ^^^ 

°'~me7erZaa 

~401 Unauthorized 



m DIAMETER UAR 



r DIAMETER UAA 

REGISTER 



DIAMBTERSAR^ 

DIAMETER SAA* 
"200 OK 



Premiere 
etape 



Seconde 
etape 



Figure 16.5 

Processus d'enregistrement d'un terminal avec VIMS 

On observe globalement deux etapes SIP dans ce scenario, correspondant a la succession 
de deux requetes et de leurs reponses. 

1. Le terminal envoie une requete SIP register, et regoit en retour une 
reponse 401 Unauthorized 

Le terminal IMS envoi sa requete d'enregistrement au serveur P-CSCF. Celui-ci ne 
connait pas necessairement le serveur I-CSCF (dans le cas general, le P-CSCF peut 
appartenir a un autre operateur que celui dont depend l'abonne). Pour localiser le I-CSCF, 
le serveur P-CSCF procede a une requete DNS a partir du nom de domaine que l'utili- 
sateur a fourni. 
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Une fois localise, le P-CSCF joint le I-CSCF en lui fournissant la requete de l'utilisateur, 
dans laquelle il a ajoute un champ d'entete P-Visited-Network-ID. Ce champ contient 
un identifiant du reseau dans lequel le P-CSCF se trouve. II permettra au S-CSCF de veri- 
fier que le reseau visite beneficie d'un accord de roaming avec l'operateur de l'utilisateur. 
Un autre champ ajoute par le P-CSCF est le champ d'en-tete Path qui specifie l'adresse 
SIP du P-CSCF. Cette information permettra de retourner la reponse a cette requete via 
ce meme serveur P-CSCF. 

Lorsque le I-CSCF re^oit la requete, il ignore si elle concerne un utilisateur qui est deja 
enregistre ou s'il s'agit d'un nouvel enregistrement. Le I-CSCF utilise le protocole 
Diameter pour contacter la base de donnees HSS et lui demander, a partir des identites 
publiques et privees contenues dans le message de requete register, d'authentifier 
l'utilisateur (requete UAR). 

Si l'utilisateur a deja ete enregistre, un serveur S-CSCF lui a deja ete attribue, et 
l'adresse de ce serveur est stockee dans la base HSS. Dans ce cas, la base HSS fournit 
dans sa reponse (message uaa) l'adresse du S-CSCF qui est en charge de la session de 
l'utilisateur. Autrement, et s'il s'agit d'une premiere connexion pour l'utilisateur, 
aucun serveur S-CSCF ne lui a ete attribue et la reponse uaa de la base HSS propose 
1' ensemble des S-CSCF disponibles avec leur caracteristiques propres, de maniere 
que le serveur I-CSCF puisse choisir l'un d'entre eux, selon un critere qu'il determine 
librement (generalement pour repartir la charge des utilisateurs equitablement entre 
tous les serveurs S-CSCF). 

Considerons dans notre scenario qu'il s'agit d'une premiere authentification : le 
serveur I-CSCF a done choisi un serveur S-CSCF pour traiter la session courante de 
l'utilisateur, et il lui relaie la requete d' enregistrement de l'utilisateur. Le S-CSCF 
contacte alors la base HSS pour 1' informer qu'il a ete designe pour prendre en charge 
la session de l'utilisateur (requete mar). II regoit en retour une reponse maa qui, d'une 
part, conflrme 1' enregistrement du S-SCSF affecte a l'utilisateur et, d'autre part, 
retourne des informations propres a l'utilisateur, qui vont permettre de generer un chal- 
lenge pour authentifier l'utilisateur (ces informations sont appelees vecteurs d' authen- 
tification). 

Lorsque le S-CSCF les regoit, il repond au serveur I-CSCF par un message SIP 401 
Unauthorized, contenant le challenge sous la forme d'un champ d'entete appele 
WWW- authentic ate. Ce message de reponse est relaye conformement au modele 
SIP client/serveur, e'est-a-dire de proche en proche, en passant par tous les emetteurs 
de requetes : le I-CSCF d'abord, le P-CSCF ensuite et le terminal client enfin. Cette 
liste de serveurs est facilement determinee car, lors de 1' envoi de la requete REGIS- 
TER, les serveurs traverses ont enregistre leur adresse SIP, grace au champ d'en-tete 
Path. 
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2. Le terminal envoie une nouvelle requete SIP register et regoit en retour une 
reponse 200 ok 

Lorsque le client regoit le message de reponse 401, il detecte le challenge qui s'y trouve 
et prepare automatiquement une reponse adaptee (sans sollicker l'utilisateur, mais en 
exploitant les donnees contenues dans la carte a puce UICC, si le terminal client en 
dispose, ou bien avec des donnees equivalentes stockees dans le terminal). 

Cette reponse est generee dans une nouvelle requete d'enregistrement register. Elle est 
envoy ee en suivant le meme processus d'acheminement que le premier message de 
requete : le terminal client ne connait que le serveur P-CSCF, qui, lui-meme, ne 
peut s'adresser qu'au I-CSCF, qui, a son tour, sous-traite la demande aupres du 
serveur S-CSCF. 

Remarquons, d'une part, que le serveur I-CSCF contacte peut etre different du premier, 
car son adresse est determinee par une requete DNS effectuee par le serveur P-CSCF. 
Or il est classique que le DNS opere une repartition de charges entre les serveurs 
I-CSCF et reponde differemment a chaque requete. D' autre part, le serveur I-CSCF 
effectue la meme requete (uar) aupres de la base HSS. En effet, comme on vient de 
l'indiquer, non seulement il peut s'agir d'un autre serveur I-CSCF que celui qui a 
relay e le premier message, mais, de plus et surtout, meme s'il s'agit du meme serveur 
I-CSCF, ce dernier n'a garde aucune trace de la requete precedente et ignore done a 
quel serveur S-CSCF adresser cette requete : e'est la base HSS qui le renseigne dans sa 
reponse (message uaa) en lui fournissant 1' adresse du serveur S-CSCF en charge de la 
session courante. 

A reception de la requete, le serveur S-CSCF verifie 1'authentification de l'utilisateur, en 
reprenant les vecteurs d'authentification que lui a fournis le HSS a l'etape precedente et 
qu'il a stockes. Si les parametres d'authentification sont valides, 1'authentification est un 
succes, et le serveur S-CSCF en informe le HSS (par un message sar). Des lors, l'utili- 
sateur peut appeler et devient joignable a l'adresse qui figure dans le champ d'en-tete 
Contact de la requete register, et ce pendant toute la duree mentionnee dans la valeur 
de l'en-tete Expires. 

Le HSS repond ensuite au S-CSCF en lui envoyant le profil complet de l'utilisateur, qui 
est stocke temporairement et servira a parametrer et personnaliser les services de ce 
dernier. 

Pour terminer, le serveur S-CSCF envoie un message de reponse 200 OK au terminal pour 
lui notifier le succes de 1' operation d'enregistrement. Ce message comporte notamment 
un champ P-Associated-URI, qui liste les adresses SIP que l'utilisateur a enregistrees 
aupres du HSS (et done avec lesquelles il est joignable), et un champ Service-Route, 
qui precise explicitement l'adresse URI SIP du serveur S-CSCF que l'utilisateur pourra 
contacter directement dans ses requetes suivantes (bien qu'elles transiteront obligatoirement 
avant par le serveur P-CSCF). 

Comme precedemment, le message de reponse traverse les entites qui ont achemine la 
requete, e'est-a-dire le I-CSCF, le P-CSCF puis le terminal IMS. 
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Mise en relation de deux utilisateurs 

Une communication implique une premiere etape de recherche des abonnes, de verifi- 
cation des autorisations d'acces, puis de mise en relation entre les correspondants. 

La methode associee a cette derniere fonctionnalite est invite avec le protocole de signa- 
lisation SIP. C'est aussi la methode que nous allons employer, mais avec une mise en 
oeuvre particuliere, dont un scenario est illustree a la figure 16.6. 



* Reseau ^Reseau de j Reseau de I'operateur de B 

I visite par A L I'operateur 




Sor nerie 



Figure 16.6 

Mise en communication de deux terminaux 



L'architecture IMS 



Chapitre 16 

Nous considerons que 1' appelant et l'appele ont des operateurs differents et sont localises 
dans des reseaux visites, c'est-a-dire qui n'appartiennent pas forcement a leur operateur 
respectif. C'est le cas le plus general. 

Ce scenario de mise en relation de deux terminaux, ou UE (User Equipment), peut etre 
decoupe en sept grandes etapes, que nous allons brievement presenter : 

1. Message d'invitation de A vers B, avec deux reponses temporaires : une reponse 100 
pour indiquer la tentative et une reponse 183 pour proposer de negocier les parame- 
tres de la communication. L' appelant sollicite le terminal de B et, pour cela, 
s'adresse au serveur I-CSCF de B, qui le localise apres une requete Diameter. 

2. Pour s'assurer que l'emetteur A a bien regu la reponse 183, celui-ci doit imperative- 
ment envoyer un acquittement temporaire. Comme toute requete SIP, et conformement 
au modele client/serveur, une reponse est envoyee. 

3. Le terminal A doit negocier les parametres de qualite de service pour garantir sa 
communication dans le reseau. Cette etape permet aux utilisateurs d'etablir une com- 
munication avec une bande passante garantie, et done un service de qualite. Elle est 
nouvelle par rapport au processus habituel d'etablissement de connexion qu'utilise 
SIP, car la qualite de service est un element essentiel avec 1'IMS. Le terminal B veri- 
fle que lui aussi a reserve les ressources necessaires a la communication dans le 
reseau et valide la requete par sa reponse. 

4. Des ce moment, le terminal de B commence a sonner. Cette etape complete les 
reponses temporaires a la requete d'invitation par une reponse 180, elle aussi tempo- 
raire. 

5. Pour s'assurer que cette reponse est bien re^ue du terminal A, ce dernier doit confirmer 
la reception par une requete d' acquittement, qui attend elle-meme une reponse. 

6. Des que l'utilisateur du terminal B a repondu (ou que sa messagerie s'est enclenchee), 
la reponse definitive 200 est envoyee a la requete initiale d'invitation. 

7. La requete d' acquittement finale valide 1' initialisation de la communication, qui peut 
des lors debuter pour permettre aux terminaux de s'echanger des flux de donnees 
multimedias. 



Conclusion 



Alors que, dans le monde IP, la telephonie n'est qu'un service banalise parmi d'autres, 
elle constitue le coeur de marche des telecoms. A cet egard, le reseau telecoms parait bien 
pauvre en comparaison du reseau Internet. 

Les operateurs doivent reflechir a ce que seront les reseaux telecoms de demain, et deci- 
der si et comment la prochaine generation de reseaux telecoms proposera une gamme de 
services plus large, incluant la telephonie, mais aussi la video et toutes les applications 
reseau que Ton connait, ou s'ils resteront confines dans les communications telephoniques, 
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reduisant leurs marges de benefices potentiels avec les services a valeur ajoutee dans un 
marche hautement concurrentiel. 

Cette seconde hypothese reduit evidemment au minimum les efforts et evolutions tech- 
nologiques et impacte vers le bas les benefices economiques des operateurs. C'est done 
dans la premiere perspective que s'inscrit 1'IMS. 

Concurrent du GAN, 1'IMS est un element constitutif central des reseaux de nouvelle 
generation, dits NGN (Next Generation Network), lesquels designent plus generalement 
le passage d'un reseau a transfert de circuits (RTC), vers un reseau a transfert de paquets 
(IP). 

L' orientation prise s'inscrit dans la notion de reseaux intelligents, ou IN (Intelligent 
Network), qui consiste a repartir l'intelligence entre toutes les entites d'un reseau, a 
l'oppose — ou a la jonction — du modele telecoms, ou toute l'intelligence et le controle 
se situent dans le reseau coeur (avec des terminaux basiques), et du modele Internet, ou 
toute l'intelligence de controle se situe dans les terminaux (avec un reseau coeur tres 
simple). 

Les reseaux IN permettent de developper un plan de controle qui allege les commuta- 
teurs en les cantonnant a leur fonctionnalite premiere, qui est de connecter et transporter 
des flux. Cela engendre des gains dans la vitesse de deploiement des services, dans la 
gestion du reseau et dans les capacites de modification, de flexibilite et d' evolution. 

L'IMS se pose a la frontiere entre deux paradigmes : le monde des reseaux IP et celui des 
reseaux telecoms. En decrivant une architecture unique, 1'IMS permet la cohesion de 
deux reseaux qui etaient, jusqu'a present, independants, voire concurrents sur de nombreux 
services, comme la telephonic 

Telle est la pretention de 1'IMS : quel que soit le reseau d'acces, faire emerger un reseau 
coeur unique, qui mutualise toutes les ressources, standardise les echanges entre les 
operateurs, unifle les services des utilisateurs, simplifle la gestion des terminaux et faci- 
lite le developpement de nouveaux services. C'est un pas necessaire dont la grande majo- 
rity des acteurs reconnaissent la necessite. C'est neanmoins une etape que peu d'acteurs 
osent encore franchir. 

En effet, si son utilite n'est pas a demontrer, le business plan de 1'IMS (et done sa renta- 
bilite) reste a etudier. Par exemple, la premiere des applications souvent mentionnees 
pour 1'IMS est le service de presence, comme sur les messageries instantanees. Mais, 
avec ce simple service, les operateurs peuvent perdre enormement d'appels, en particu- 
lier ceux qui aboutissent sur messagerie. Or 1' infrastructure d'un reseau IMS a un cout 
relativement important pour les operateurs qu'il faut, au contraire, rentabiliser. 

Toutefois, les possibilites sont si grandes et le service rendu aux utilisateurs si important 
qu'il est assez probable qu'une nouvelle forme de consommation va emerger avec 1'IMS. 
Nul doute qu'un tel reseau donnera une forte valeur ajoutee aux operateurs qui le propo- 
seront et que, tres vite, les concurrents devront suivre le mouvement pour ne pas se laisser 
distancer sur ce terrain tres prometteur. 
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Liens web 

Sites de vulgarisation de la TolP 

http://www. voip-info.org (anglais) 

Un site incontournable, qui s' impose par la diversite des articles proposes. Cette 
immense source d' informations melange l'actualite de la TolP et les tutoriaux dans tous 
les domaines de la VoIP. Le site s'adresse a tous les utilisateurs, du debutant, qui y trou- 
vera les bases fondamentales pour commencer son approche, aux professionnels, qui y 
trouveront des ressources consequentes pour approfondir leur etude. 

http://www. en. voipforo. com (anglais) 

De nombreuses Aches traitant de sujets divers, comme la numerisation de la voix, la 
qualite de service, les protocoles H.323 et SIP, les softphones ou encore le PBX Asterisk. 

http://www. voipplanet.com (anglais) 

Actualites, solutions, tests et tutoriaux pour les specialistes de VoIP qui veulent connaitre 
et approfondir les notions pratiques de la telephonic 

http://www. voipfr. org 

Un site non technique presentant des informations de maniere claire et precise sur les 
evolutions du marche de la TolP et des offres commerciales. 

http://www. testyourvoip. com (anglais) 

Un outil permettant de tester la qualite d'une communication telephonique. 

http://www. multimedia. ex (anglais) 

Une base de liens dediee au multimedia. Un wiki decrit de maniere complete la liste des 
codecs audio et video. 

http://www. 1 net. com 

Un site sur toutes les technologies informatiques traitees de bout en bout, de la promesse 
a l'actualite, avec des retours d' experience sur le terrain. Un bon moyen de suivre les 
tendances de 1'informatique en general et de la telephonie en particulier, qui y est un 
theme largement couvert. 

http://www. reseaux-telecoms. net 

L'actualite informatique des telecoms, avec les evolutions du marche analysees par des 
experts. 

http://fr. wikipedia. org 

La celebre encyclopedic en ligne, libre et gratuite, qui contient enormement d' informa- 
tions et de sources sur les themes les plus divers de la telephonie, depuis les protocoles 
jusqu'aux logiciels clients, en passant par les normes de codage et les principaux acteurs 
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du marche. Les fiches sur les protocoles H.323, SIP et Jabber sont une bonne premiere 
approche. 

Protocoles de TolP 

http://www.itu.int (anglais) 

Le site de 1'ITU (International Telecommunication Union) 

http://www.ietf.org (anglais) 

Le site de 1'IETF (Internet Engineering Task Force) 

http://www.ietf. org/html. charters/sip-charter. html (anglais) 

La page de reference du protocole SIP, qui presente les travaux realises et en cours. 

http://www.packetizer. com/voip/ (anglais) 

Une tres bonne base de documents, classee par protocoles et organisee en sections (docu- 
ments de specification des standards, groupes de travail, mailing lists, forum de discussion, 
liens connexes, etc.) 

http://www.h323forum.org (anglais) 

Forum H.323 soutenu par 1'IMTC (International Multimedia Telecommunications 
Consortium). On y trouve des discussions techniques autour des themes centraux relatifs 
a H.323, ainsi que la liste exhaustive des standards, incluant les annexes. 

http://www.sipf orum. org (anglais) 

Le forum SIP, annon^ant notamment les principaux evenements internationaux concernant 
SIP. 

http://www.sipcenter. com (anglais) 

Un site couvrant tous les aspects de SIP, de ses specifications protocolaires a ses evolu- 
tions futures, en passant par des outils de test d'interoperabilite d'une implementation 
avec SIP, une comparaison avec H.323, son interaction avec MGCP ou encore le passage 
des pare-feu. 

http://www. cs. Columbia, edu/sip/ (anglais) 

Un site tres complet sur les acteurs promouvant SIP, avec un historique exhaustif de la 
normalisation, des outils de tests, d' analyse et de performance du protocole SIP, ainsi que 
de tres nombreux liens, tutoriaux et informations pratiques. 

http://www. tech-invite. com (anglais) 

Portail technique dedie au protocole SIP et a TIMS. 

http://www.xmpp.org (anglais) 

Liste des travaux et documents de travail sur XMPP (Extensible Messaging and Presence 
Protocol), le protocole mis en oeuvre dans la plate-forme Jabber. 
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http://www.3gpp.org (anglais) 

Site Web du 3GPP, qui a pour objectif de standardiser 1'IMS en partant de la technologie 
GSM (en Europe). 

http://www.3gpp2.org (anglais) 

Site Web du 3GPP2, qui a pour objectif de standardiser 1'IMS en partant de la technologie 
CDMA 2000 (aux Etats-Unis et en Asie). 



Softphones et derives 

http'J/www. voipproducts.eu (anglais) 

L'actualite des softphones et une comparaison, actualisee regulierement, des tarifs 
proposes. On y retrouve, entre autres, les incontournables WLM, Yahoo! Messenger 
Voice et Google Talk. 

http://www. wengophone. fr/index.php 

Site de telechargement du logiciel Wengo, avec les sources du logiciel ouvert. 

http://www. skype. com 

Site de telechargement du logiciel Skype. 

http://developer.skype.com/ (anglais) 

Cette page recense les informations permettant aux developpeurs d'integrer certaines 
fonctionnalites de Skype a leur application, et d'en concevoir de nouvelles avec les API 
fournies. 

http'J/www. windows! ive. fr/messenger/ 

Site de telechargement du logiciel WLM de Microsoft. 

http://fr. messenger.yahoo. com 

Site de telechargement du logiciel Yahoo! Messenger. 

http://developer.yahoo. com/messenger/ (anglais) 

Telechargement et documentation du kit de developpement (ou SDK) permettant aux 
developpeurs independants de concevoir leurs propres outils et plug-in pour Yahoo! 
Messenger. 

http://www.google.com/talk/intl/fr/ 

Site de telechargement du logiciel Google Talk. 

http://www. jabber. org (anglais) 

Le site de la Fondation Jabber. II contient des listes tres completes de clients ou de 
serveurs compatibles avec la plate-forme Jabber. Le site contient egalement des 
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bibliotheques de codes source de 1' implementation du protocole. On y trouve aussi 
des explications sur le protocole XMPP, et les origines et ambitions de la Fondation. 

http://www.jabberfr. org 

Un site tres complet et resolument pratique qui permet de se familiariser avec Jabber. 
Aux debutants comme aux experts, ce site propose des tutoriaux tres clairs ainsi qu'un 
forum pour s'entraider et une liste de liens pour poursuivre son etude. 

http://www.ekiga.org (anglais) 

Site de telechargement du logiciel Ekiga (anciennement GnomeMeeting), Tune des 
applications libres et gratuites les plus reputees pour la gestion des conferences multimedias. 
Le logiciel supporte a la fois le protocole H.323 et SIP. 

http://www. counterpath. com (anglais) 

Site de telechargement du logiciel X-Lite permettant de communiquer en utilisant le proto- 
cole SIP. Le softphone emule un terminal telephonique et integre des fonctions classiques, 
comme l'acces a sa messagerie pour peu que la configuration avec le serveur soit parametree. 

http://www.sjlabs. com (anglais) 

SJPhone, le softphone compatible H.323 et SIP tres riche en fonctionnalites et disposant 
de guide d' utilisation pour utilisateurs debutants et avances. 

http://www. bewip. com 

Softphone a installer sur des appareils communicants, de type PDA ou SmartPhone, et 
permettant de selectionner intelligemment le reseau GSM ou Wi-Fi selon les disponibili- 
tes et tarifs. 

http://gizmoproject.com/intl/fr/ 

Un softphone qui permet la mise a disposition d'une boite vocale pour les utilisateurs, et 
l'avantage d'utiliser le standard SIP, permettant notamment de l'utiliser conjointement 
avec le logiciel Asterisk. 

http://www.jajah. com 

Ce site propose un moyen original de telephoner. L'utilisateur saisit sur une page Web 
son numero de telephone puis celui de son correspondant. Les deux telephones sonnent 
et sont mis en relation pour que la communication debute. En reseau coeur, c'est la tech- 
nologie IP qui est utilisee, tandis qu'aux extremites, une passerelle assure la conversion 
du signal vers un reseau telephonique classique. 

http'J/www. mylivio. com 

Ce nouveau venu dans le pay sage du Web propose aux webmasters d'integrer a leurs 
pages Web des boutons d'appel qui permettent aux visiteurs de leur telephoner, que ce 
soit sur un telephone fixe ou un portable. Le service est totalement gratuit et finance par 
la publicite. 
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PBX Asterisk 

http://www. asterisk. org (anglais) 

Le site de reference pour telecharger le logiciel Asterisk ainsi qu'un ensemble de modules 
additionnels et installer le tout sur une distribution quelconque. La section Supportfournit 
une source d' information tres utile lorsqu'on rencontre des difflcultes avec Asterisk. 

http://www. voip-info.org/wiki/index.php ?page=Asterisk 

Une base tres complete et parfaitement documentee, avec de nombreux tutoriaux, sur des 
aspects tres divers de la configuration a 1' optimisation du serveur Asterisk. Ce site donne 
egalement acces au manuel des commandes d' Asterisk. A ce titre, le moteur de recher- 
che est particulierement utile pour connaitre ou verifier la syntaxe exacte des commandes 

http://www. asterisknow. org (anglais) 

Asterisk Now est une distribution complete pour installer un serveur Asterisk en un 
temps record de trente minutes, avec des interfaces de configuration et des outils de 
gestion du serveur. 

http://www. asteriskguru. com (anglais) 

Mis a jour assez frequemment, ce site propose des tutoriaux pour se familiariser avec 
Asterisk ou approfondir certaines notions. De nombreuses informations sont fournies sur 
les nouveautes apportees au logiciel. Des utilitaires sont disponibles pour ameliorer le 
fonctionnement d' Asterisk. Un forum tres actif permet de trouver de l'aide en cas de 
probleme. 

http://www. asterisk-france. net 

Des informations diverses sur l'actualite du logiciel phare Asterisk mais aussi des 
conseils et explications techniques et pratiques pour comprendre et optimiser 1' utilisation 
du logiciel. On y trouve egalement des tutoriaux pour Installation et les parametres de 
fonctionnement d' Asterisk. Un forum d'entraide est propose. 

http://www. freepbx. org (anglais) 

Un outil graphique pour parameter Asterisk sous Linux, selon ses besoins et grace a des 
interfaces Web. La documentation fournie est dense et couvre tous les aspects pratiques. 

http://www. digium. com (anglais) 

Le site de la societe mere du logiciel Asterisk. 

http://www. eikonex. net 

Site de formation au logiciel Asterisk et de vente de materiel compatible avec le produit 
et adapte a differents besoins. 

http://www. sipfoundry. org (anglais) 

SipX, une solution de rechange a Asterisk tres robuste mais dedie exclusivement a SIP. 
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2 e edition 



Technologies et solutions de telephonie sur IP 

La telephonie sur IP s'impose progressivement dans tous les secteurs : la convergence vers 
un reseau tout IP s'accelere dans les entreprises, les fournisseurs d'acces generalisent leurs 
offres triple-play et quadruple-play incluant le service de telephonie sur IP, des logiciels comme 
Skype, WLM, Yahoo! Messenger ou Google Talk sont entres dans les habitudes, sans parler 
de la telephonie mobile qui devient hybride et s'adonne aux bienfaits du reseau IP. 

Ce livre offre un vaste panorama des technologies et des solutions de telephonie sur IP. 
Qu'apporte ce modele par rapport au reseau telephonique traditionnel? Quels sont les pro- 
tocoles mis en oeuvre? Comment garantir la qualite de service, la securite et le nomadisme? 
Quelles sont les difficultes rencontrees et comment les contourner? Quelles sont les archi- 
tectures types a deployer en entreprise? Quels sont les logiciels grand public qui proposent 
ce type de service et comment les utiliser? Comment installer et maintenir gratuitement 
son propre PBX avec Asterisk? Que nous reserve la telephonie du futur? Telles sont les 
questions auxquelles ce livre tente d'apporter une reponse. 

Cette seconde edition s'enrichit de nombreux complements et exemples sur les dernieres 
evolutions des technologies et des solutions logicielles et inclut, en particulier, un nouveau 
chapitre dedie a I'architecture IMS (IP Multimedia Subsystem). 



Au sommaire 

La theorie. Problematique de la TolP • Les contraintes de la VoIP • La signalisation H.323 • 
Le protocole SIP • Le protocole MGCP • La qualite de service • Architectures et 
securite (TolP sur Ethernet, ATM, relais de trames, Wi-Fi, WiMax...). Les solutions pratiques. 
La TolP sur softphones • Skype • Windows Live Messenger et Yahoo! Messenger • 
Jabber et Google Talk • Asterisk : une solution logicielle de PBX, libre et ouverte • Offre des 
fournisseurs d'acces (TolP sur xDSL, CATV...) • Filtrage des flux de TolP (NAT et pare-feu). 
Perspectiues. Les cinq problemes cles de la TolP • L'architecture IMS. 
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